Freitag, 17. Januar 2014

Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.

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.


Zu dem Artikel Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung? wurde ich darauf hingewiesen, dass Wissensbrüche immer entstehen, wenn dokumentenzentriert und nicht lernzentriert gearbeitet wird. Des weiteren wurde mir empfohlen, mich mit dem Buch "Software entwickeln mit Verstand" [DIR11] auseinanderzusetzen. Das habe ich mit Gewinn getan. Eine Grundthese des Buches ist: "Softwareentwicklung ist Wissensarbeit." [S.27, DIR11] Mit dem Begriff der Wissensarbeit setzt man sich zum einen von der Auffassung ab, Softwareentwicklung könnte wie moderne tayloristische Industrieproduktion organisiert werden, und zum anderen möchte man zeigen, es ist Entwicklungsarbeit, besser Forschungsarbeit, in der es gilt Wissenslücken zu schließen. Diese Wissenslücken schaffen eine Barriere, die überwunden werden muss. "Charakteristisch für die Wissensarbeit ist die zwischen Ausgangs- und Zielzustand liegende Barriere, die der Wissensarbeiter überwinden muss, um eine Lösung zu entwickeln." [S.26, DIR11] "Die Barriere zu überwinden heißt, die Wissenslücke zu schließen." [S.27, DIR11]

In meinem Artikel Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung? stellte ich die Behauptung auf, dass zwischen Fachbereich und Entwicklung ein besonderer Wissensbruch existiert. Das Begriffs- und Modellwissen des Fachbereichs, z.B. eines ausgebildeten Betriebswirtschaftlers, und des Entwicklungsbereichs, z.B. ausgebildeten Informatikern, sind nicht aufeinander abgestimmt. Diese Nichtabstimmung habe ich als eklatanten Wissensbruch bezeichnet. Das Wissen des Fachbereichs und der Entwicklung bezieht sich auf ganz verschiedene Wissensgebiete. In [DIR11] wird ein Modell des Gehirns verwendet, welches zwischen Langzeitgedächtnis und Arbeitsgedächtnis unterscheidet. "Das Langzeitgedächtnis enthält eine große Menge vernetzten Wissens. Dazu gehören die für die Erkennung notwendigen Muster, Operatoren, Handlungsstrategien und Rezepte." [S44, DIR11] Menschen aus dem Fachbereich und Menschen aus der Entwicklung sammeln in ihrem Ausbildungs- und Arbeitsleben ganz unterschiedliches Wissen. Ein Student der BWL erlernt bestimmte Modelle, Definitionen und Begriffe. Als Mitarbeiter einer Bank baut er dieses Wissen aus, in dem er die Begriffswelt der Bank absorbiert, in der er arbeitet. Ganz andere Modelle, Definitionen und Begriffe erlernt ein Student der Informatik. Auch dieses Wissen baut er später als Entwickler aus. Durch diese verschiedenen Begriffswelten entstehen in der Kommunikation Irritationen. Hinter gleichen Begriffen können ganz unterschiedliche Modelle stehen. Im Kreislauf der Wahrnehmungs- und Darstellungstransformation entstehen Missverständnisse und dass nicht nur, wenn über Dokumente kommuniziert wird.



In [DIR11] werden vier Wissensgebiete aufgezählt, in denen Wissenslücken geschlossen werden müssen, um ein Softwareprojekt umzusetzen: Markt, Domäne, Prozesse/Experience und Technologie. "Eine gute Software entsteht dadurch, dass das Team die Abhängigkeiten zwischen Markt, Experience, Domäne und Technik schnell findet und eine Lösung entwickelt, die die Bedürfnisse in allen vier Bereichen genügend erfüllt. Dazu ist intensive Zusammenarbeit der Wissensträger notwendig." [S.217, DIR11] Wissensträger unterschiedlicher Wissensgebiete sind also dazu "verdammt", miteinander zu arbeiten und ihre Begriffe, Modelle, Definitionen, Muster und Rezepte so aufeinander abzustimmen, dass sie miteinander sinnvoll kommunizieren und arbeiten können. Durch die hohe Arbeitsteilung innerhalb der modernen Gesellschaften bilden wir Spezialisten heraus, die in ihrem Spezialgebiet ein hohes Wissen herausgebildet haben. Die von mir beschriebene Schwierigkeit liegt in der Kommunikation über Spezialgebiete hinweg. Im gesamten Team, welches sich aus unterschiedlichen Spezialisten zusammensetzt, ist ein allgemeines mentales Modell notwendig, über das das Team kommuniziert und gemeinsam an einer Lösung arbeiten kann.

Die Kommunikation der verschiedenen Spezialisten kann auf die direkte Kommunikation nicht verzichten. Begriffe müssen hinterfragt und abgeglichen werden, genau wie Modelle, Muster und Rezepte. Eine Kommunikation, die rein über Dokumente erfolgt, wäre dazu nicht geeignet. Dokumente können die Ergebnisse der gemeinsamen Diskussion festhalten, sie sind nicht das geeignete Mittel zum Wissenstransfer. Großen Gewinn ziehen wir später aus ihnen, wenn wir uns an die gemeinsame Diskussion erinnern und so die mentalen Modelle auffrischen. Die angesprochene Kommunikation ist erschwert, wenn sie mit Menschen außerhalb des Teams läuft. In [DIR11] wird vom Kontext gesprochen. Es handelt sich also um Stakeholder, die nicht Mitglied des Teams sind, jedoch über wertvolles Wissen zum Softwareprojekt verfügen. In [DIR11] kommen die Autoren zu dem Schluss, "dass in solchen Fällen die Kommunikation mit Leuten außerhalb des Projektteams umso erfolgreicher verläuft, je besser diese in einen gemeinsamen Problemlöseprozess eingebunden sind." [S.128, DIR11] Als externe Mittel, um diese Kommunikation zu gestalten, werden Storyboard, Skizzen und Prototypen von User Interfaces empfohlen.

 

Der Kommunikation mit dem Kontext kommt zusätzlich eine hohe Bedeutung zu. "Die Interaktion mit dem Kontext, also beispielsweise mit den Benutzern und Auftraggebern, ermöglicht dem Team, sich richtig auszurichten und zu adaptieren. Erst hierdurch kristallisieren sich nach und nach die richtigen Projektziele heraus. Damit die Interaktion stattfinden kann, liefert das Team Ergebnisse an ausgewählte Leute im Kontext." [S.157, DIR11] Theoretisch ist also eine enge Kommunikation mit dem Kontext eine wichtige Voraussetzung, um ein erfolgreiches Softwareprojekt umzusetzen. Praktisch ist die Einsicht in diese Zusammenhänge nicht gegeben und den Beteiligten wird für die notwendigen Aktivitäten keine Zeit gegeben. Das kann man sicherlich nicht pauschalisieren, habe ich in meinem Erfahrungsbereich jedoch oft beobachtet. Die fehlende Tiefe eines gemeinsamen Kommunikationsprozesses zwischen Projektteam und Kontext stellt somit zumindest einen Hauptgrund für die Verzögerung, das Scheitern oder teilweise falsche Umsetzen von Projekten dar.

Weil die Interaktion mit dem Kontext ein wesentlicher Grund für den Erfolg eines Softwareprojektes ist, möchte ich die von [DIR11] aufgeführten drei Gründe hier noch einmal erwähnen: "
  • Die Ansprüche der Personen rund um das Projekt müssen verstanden werden. Dies verlangt intensive Kommunikation. Nur so kann ein Team es schaffen, das Richtige zu bauen.
  • Die Dynamik im Kontext und die Wechselwirkung mit dem Team verändern den Kontext und damit die Ansprüche. Ein Team muss am Puls des Geschehens sein und auch Veränderungen anstoßen. Nur so kann ein Team diese Dynamik erkennen und sich anpassen.
  • Die Treiber der Teamdynamik sind die Ansprüche und die Rückmeldungen aus dem Kontext. Es braucht regelmäßiges Feedback zu den erstellten Ergebnissen, nur so kann sich das Team zielgerichtet weiterentwickeln.
" [S.194, DIR11]

Zum Schluss dieses Artikels möchte ich noch einmal darauf hinweisen, dass die tiefe Analyse des Systemkontextes für mich zentraler Bestandteil des Erstellens optimaler Software ist. Dazu wurden in diesem Blog bereits die folgenden Artikel veröffentlicht:
Im Prozessmodell sind also Schritte vorzusehen, die der Kommunikation zwischen Kontext und Projektteam gerecht werden. Ein enges Binden des Kontextes an das Projektteam muss dabei zentrales Anliegen sein. Ein wirkliches Einbinden von Stakeholdern in das Projektteam wäre natürlich ideal.

  • [DIR11] : Jörg Dirbach, Markus Flückiger, Stefan Lentz: "Software entwickeln mit Verstand", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2011


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