Freitag, 3. Januar 2014

In Softwareprojekten gibt es viel zu entdecken!

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.


Viele Softwareprojekte sind innovativ und komplex. In diesen Projekten muss notwendigerweise fehlendes Wissen erarbeitet werden. An welchen Stellen im Vorgehen sind dafür Zeiten und Ressourcen vorgesehen? Nehmen wir Scrum. Scrum kennt sogenannte Explorationssprints. Diese Sprints werden den Standardsprints vorgelagert. "Wesentliches Ziel der Explorationssprints ist es, mithilfe von organisierten Experimenten Risiken zu adressieren und das zur Umsetzung der Anforderungen benötigte Wissen zu generieren". [S.56, PICH09] In diesen Sprints müssen keine auslieferbaren Produktinkremente erstellt werden. Es ist Zeit für Experimente aller Art. Man kann Designer- und Technologiestudien durchführen, Prototypen erstellen, Erfahrungen sammeln und vieles mehr.

Diese Form der Entdeckungsarbeit wird jedoch auch in Scrum eher als schmerzlicher Verlust an der Zeit betrachtet, die für die „eigentliche“ Arbeit am Produktinkrement gedacht ist, welches Geschäftswert zu liefern hat. Ich denke jedoch, dass die Erarbeitung von Wissen ein verdeckter Geschäftswert ist. In einem Zeitalter, in dem anscheinend nur das offensichtliche als Geschäftswert anerkannt ist, ist es anscheinend sehr schwer, bewusst zu machen, dass Softwareentwicklung oft mehr mit Forschungsarbeit zu tun hat, als Produktionsarbeit ist. Hier ist der ökonomische Wunsch Vater des Gedanken, etwas messbar zu machen, was kaum messbar ist. Wer hätte schon sagen können, wie lange es dauert die Relativitätstheorie zu entwickeln oder die Röntgenstrahlen zu entdecken. In Softwareprojekten möchte man jedoch wissen, für wie viel Geld man was bekommt und das auch, wenn es nicht geht. Oft wird an Zeitpunkten eine Schätzung gefordert, an der weder die ungefähren Anforderungen klar sind, noch die Risiken der erwähnten Forschungsarbeit. Zu 90% wird einfach irgendeine Zahl in den Raum geschleudert und am Ende wundert man sich, warum die Schätzung so danebenging. Ich würde dafür nicht einmal das Wort Schätzung benutzen, sondern Selbstbetrug.



Jörg Dirbach, Markus Flückinger und Steffen Lentz beschreiben in ihrem Buch "Software entwickeln mit Verstand" die Entwicklung von Software deshalb auch eher als Wissensarbeit. Sie verneinen die Auffassung, dass Softwareentwicklung ein Herstellungsprozess ist. "Der Weg zur entwickelten Software kann nicht im Voraus detailliert beschrieben werden." [S17, DIR11] Der Entwickler muss Wissenslücken schließen, um ein Problem zu lösen und somit Anforderungen an das zu erschaffende Produkt gerecht zu werden. Diese Arbeit könnte er alleine nachgehen. In unserer heutigen Zeit und bei der Größe der Projekte ist es jedoch oft Teamarbeit. Diese Teams bestehen oft aus unterschiedlichsten Spezialisten, deren vorrangigste Aufgabe es ist, eine geeignete Kommunikation zu führen, damit man gemeinsam an der Problemlösung arbeiten kann.

Folgen wir dieser Auffassung, bekommen Explorationen eine ganz andere Bedeutung. Im Zentrum solcher Forschungsarbeit steht das Experiment. Man sucht nach Operatoren, mit deren Hilfe man eine Lösung des Problems erreichen kann. Für diese Versuche muss es Zeit geben. Die erstbeste Lösung ist nicht die beste Lösung. Die beste Lösung im technischen Sinn muss nicht die beste Lösung im ökonomischen Sinne sein. Die beste ökonomische Lösung ist oft jedoch auch nicht die am schnellsten gefundene Lösung. Diese ist oft nicht wirklich durchdacht und die Kinderkrankheiten dieser Lösungen fordern später ihren Tribut. Dieses Dilemma gilt es zu lösen und wie so oft gibt es dafür keine einfache Lösung. Explorationen stehen also im Zentrum der Wissensarbeit. Sie sind vom eigentlichen Vorgehen nicht abzuspalten und müssen in allen Schritten der Softwareentwicklung möglich sein.

"Die meisten Vorgehensmodelle schweigen sich über explorative Tätigkeiten mehr oder weniger aus." [S.178, DIR11] Eine Vorgehensweise, bei der alles Wissen beim Stakeholder abgeholt werden muss, greift laut [DIR11] zu kurz. Der Kontext, in dem sich die Stakeholder befinden, und das Entwicklungsteam müssen gemeinsam an einer Lösung arbeiten. In den Köpfen aller Beteiligten muss ein mentales Modell entwickelt werden, welches als Kommunikations- und Arbeitsbasis dient. Dieses Modell ist nur durch gemeinsame Wissensarbeit herzustellen. Diese Arbeit ist Lern- und Lehrarbeit zugleich sowie gemeinsames Experimentieren. Der "Kunde vor Ort" (customer on-site) ist in agilen Methoden ein Lösungsansatz für dieses Problem. Damit wird die Wichtigkeit der Kommunikation zwischen Auftraggeber und Auftragnehmer unterstrichen.

"Softwareentwicklung folgt einer Struktur: (1) Problemraum erkunden, (2) Ziel und Strategie fassen und (3) Problem in allen Details lösen." [S.64, DIER11] Diese Schritte werden auch als Folge von Exploration – Vision – Evolution beschrieben. In allen Teilaufgaben kann man diese Folge wiederfinden, im Requirements Engineering, in der Softwarearchitektur und in der Programmierung. Auf diese Art und Weise ist es möglich die vorhandenen Wissenslücken zu schließen. "In der Exploration erkundet ein Team den Problemraum, typischerweise durch Ausprobieren. In der Vision stößt das Team zum Kern von Problemverständnis und Lösungsidee vor. Dazu ist die Reflexion über die beim Ausprobieren erzeugten Wirkungen notwendig. In der Evolution werden Teillösungen iterativ zu einer immer vollständigeren Lösung erweitert, die möglichst gut die Vision erfüllt." [S.177, DIR11]



Der beschriebene Ansatz beinhaltet in allen Teilschritten diese Folge von Exploration,Vision und Evolution. Nur die Evolution besitzt in der großen Breite ökonomische Aufmerksamkeit und wirklich geplante Zeit und das, obwohl sie nur Folge von Exploration und Vision ist. Da die ersten beiden Schritte jedoch kaum schätzbar sind, vernachlässigt man sie. Was nicht sein soll, das gibt es auch nicht. Ein typisch menschliches Verhalten, wenn man einen Prozess kontrollieren will. Trotzdem wir immer wieder die Erfahrung machen, mit diesem Ansatz zu scheitern, lassen wir uns davon kaum beeindrucken. Ein wichtiger Ansatz wäre also die Erkenntnis, Softwareentwicklung ist auch Forschungsarbeit. Forschungsarbeit ist in ihrem Ergebnis nicht schätzbar, man kann sie zielgerichtet steuern und für optimale Ergebnisse optimale Bedingungen schaffen. Sinnloser Zeitdruck gehört sicherlich nicht dazu. Management ist eben ein Dienst an der Sache und keine Herrschaft über Menschen und Dinge.

Auf dem weiteren Weg der Verbesserung von Prozessen zum Erstellen und Betreiben von Software muss die Exploration in der Entwicklung also eine zentrale Stelle einnehmen. Ich wäre Ihnen sehr dankbar, wenn Sie meinen Horizont auch in Bezug auf dieses Problem mit Ihren Erfahrungen erweitern könnten. Besonderes Interesse habe ich an der Frage, ist alle Softwareentwicklung Wissensarbeit? Kann man Prozesse abspalten, die eher einem Herstellungsprozess unterliegen und die genau planbar sind? Wie sieht es mit der Arbeitsteilung in diesen Prozessen aus?

Zum Schluss meines Artikels möchte ich noch auf eine rein organisatorische Angelegenheit meines Blogs zu sprechen kommen. Zum Jahresanfang möchte ich den Blog zum Frei-Tags-Blog machen. Das deutet an, ich werde jeden Freitag einen Artikel veröffentlichen. Das ist ein fester Termin, den man sich gut merken kann. Der Freitag ist der Start in das Wochenende, eine Zeit in der viele sich entspannen und Kraft für die kommende Woche sammeln. Vielleicht könnte man Arbeit jedoch auch so organisieren, dass wir uns nicht ins Wochenende retten müssen und das, was wir machen, gern machen und ein ganzer Teil der Entspannung in dem liegt, was wir tun? Für einen Teil mag das schon so sein, für einen weiteren Teil, ich befürchte, der größere Teil, ist das leider nicht der herrschende Zustand. Weiterhin denke ich, ein großer Teil ist schon jetzt vom eigentlichen Inhalt seiner Arbeit fasziniert, es sind andere Dinge, ich nenne sie mal äußere Umstände, die uns in der Arbeitswoche die Laune verhageln. Kann man Wege der Besserung finden? Das ist noch so eine Frage, die mich beschäftigt. Für das Jahr 2014 wünsche ich Ihnen an dieser Stelle Gesundheit, Freude an dem was Sie tun und viele liebe Menschen um Sie herum!

  • [DIR11] : Jörg Dirbach, Markus Flückiger, Stefan Lentz: "Software entwickeln mit Verstand", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2011
  • [PICH09] : Roman Pichler: "Scrum - Agiles Projektmanagement erfolgreich einsetzen", 1. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2009


vorheriger Post dieses Themas     folgender Post dieses Themas


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

Kommentare:

  1. Lieber Herr Baumann, es freut mich sehr, dass Sie sich so intensiv und hintergründig mit den Fragen der Softwareentwicklung beschäftigen und diese Gedanken in wirklich gut geschriebenen Blogartikeln reflektieren. Das war auch unsere Idee beim Schreiben des Buches "Software entwickeln mit Verstand", hier einen Beitrag zum grundlegenden Verständnis von Wissensarbeit zu schaffen. Es freut mich sehr, dass Sie an unsere Gedanken anknüpfen und diese weiter vertiefen und auch öffentlich machen. Vielen dank dafür.
    Jörg Dirbach

    AntwortenLöschen
  2. Dass das Wort Explorationssprint erfunden werden musste, zeigt aus meiner Sicht, dass in der IT-Branche viele Pseudo-Agilisten unterwegs sind.

    Exploration gehört in jeden Sprint, in jede User Story oder wie man seine Arbeitspakete nun eben nennen mag. Klar müssen am Anfang des Projektes mehr Techniken erprobt werden, als später, aber auch in späteren Projektphasen bleibt das doch nicht aus.

    Auch finde ich, dass der Ansatz "Eliminate Waste" manchmal übertrieben wird. Generell sollte man natürlich keine Technik-Spielereien oder fachlich unnötige Features einbauen, denn das trägt nicht offensichtlich zum Business Value bei, aber aus "Müll" entsteht eben Erfahrung und manchmal eben doch einen Wert.

    AntwortenLöschen