Auf dem Software Bau

Iteration oder Fokus?

Software Bau: kann so (im übertragenen Sinne) ein Software-Großprojekt aussehen? (Bild: USACE HQ via Flickr)

Wir sprechen immer von Software Entwicklung und verschleiern damit den Teil, den man besser als Software Bau bezeichnen sollte. Software Bau unterscheidet sich von Software Entwicklung durch einen stärkeren Fokus auf Effizienz in der Ausführung und weniger auf Korrektheit von Annahmen.

Der ehemalige Software Entwickler und UX Berater Alan Cooper, beschreibt den Unterschied zwischen Software Engeneering und Software Construction (Software Bau) wie folgt:

Engineering is where the technical construction issues are identified and examined, and the construction tools and techniques are determined. Construction is where the product is built, tested, debugged, and fine tuned.

Vier Schritte in der Software Entwicklung

Ich habe neulich eine alte Keynote Rede von Alan Cooper gelesen. Darin teilt er den Softwareentwicklungsprozess in vier Schritte auf:

  1. Big idea
  2. Design
  3. Engeneering
  4. Construction

Der erste Schritt wird nicht näher betrachtet. Cooper sagt grob, dass es dort um die Vision und das Produkt-Thema gehe. Design umfasst Punkte wie Analyse, Konzeption, UI Design und so weiter. Engeneering beinhaltet die Gespräche und Überlegungen die Entwickler eben so haben—untereinander und natürlich auch mit anderen Teammitgliedern. Construction ist der Teil in dem Software tatsächlich gebaut wird.

Das ist ohne Frage alles sehr linear. Alan Cooper macht dann auch den üblichen Trick: er legt alle Schritte übereinander und malt einen Kreis dazu, schließlich hält er den Vortrag auf einer Konferenz zu Agiler Softwareentwicklung.

Software Bau mit Alan Cooper

(Alan Cooper, The Wisdom of Experience. Via coper.com)

Einige Slides weiter überarbeitet Cooper diese Darstellung, aber dazu später mehr.

Software Bau

Während die ersten drei Phasen vor allem Fragen stellen (Was ist die Produkt-Vision? Wer sind die Kunden? Was benötigen die Kunden? Was ist der Anwendungskontext? Technische Anforderungen? Zeitplan der Umsetzung? …) geht es bei der vierten Phase (Construction) nicht um Fragen, sondern um Umsetzung.

Und während die ersten drei Phasen (Big idea, Design, Engeneering) unbedingt um Richtigkeit bemüht sind (Zielgruppe richtig einschätzen, richtige Anforderungen erfassen, richtige technische Entscheidungen treffen …) geht es bei der letzten Phase um Effizienz, da man die Richtigkeit der bisherigen Schritte voraussetzt. Die letzte Phase, der Software Bau, ist also stark von Produktivität getrieben.

Während die ersten drei Phasen irgendwie von Zusammenarbeit und Diskussionen und multidisziplinärem Austausch und unvorhersehbarer Inspiration befeuert werden, geht es in der letzten Phase nur um Flow. Es geht darum möglichst umfassend und lange im Zustand des produktiven Arbeitens zu bleiben. Da sind lange Meetings und Gruppentherapien wie Scrum sie beispielsweise so gerne kultiviert oft störend.

Während die ersten drei Phasen mehr oder weniger iterativ arbeiten und Ideen und Konzepte testen und verwerfen oder aufeinander aufbauen lassen, geht es in der letzten Phase nur um linearen, schrittweisen Fortschritt. Wie auf dem Bau.

In der letzten Phase ist niemand bereit noch großartig gewählte Datenbanken zu switchen, Frameworks zu tauschen oder Design Schulden abzubauen.

Das Große Ganze

Ok, die letzte Phase (Software Bau) profitiert also nicht von den vielen Zeremonien und dem Balast den Scrum so mit sich bringt. Aber wie viele von uns täglich schmerzlich merken, passen Recherche und Ideenfindung und zumindest grobe Konzeption auch nur bedingt in den engen Scrum-Fahrplan. Zu der Erkenntnis kommt Cooper natürlich auch:

Software Bau mit Alan Cooper

(Alan Cooper, The Wisdom of Experience. Via coper.com)

Das überarbeitete Diagramm lagert Construction und Research aus der Scrum-basierten Arbeitsweise aus. Die Unterschiede für die jeweilige Auslagerung mögen nicht die Selben sein. Im Grunde macht diese Herangehensweise aber Sinn.

Das soll nicht heißen, dass in Phasen wie Ideation, Research und Conception nicht iterativ gearbeitet würde (man schaue sich nur mal die Herangehensweise von Human-centered Design an). Aber diese Phasen bringen ihre eigenen Prozesse bereits mit. Es ist nicht nötig ihnen auch noch das Scrum-Korsett überzustülpen.

About Jan (501 Articles)
Informationsarchitekt und Konferenz-Veranstalter (IA Konferenz, die Konzepter-Konferenz: http://iakonferenz.org, MOBX Mobile UX Konferenz: http://mobxcon.com), Podcaster und Twitter Addict. Geboren in Prag, sesshaft in Berlin.

Leave a comment

Your email address will not be published.


*


css.php