Direkt zum Hauptbereich

Software Craftsmanship - The New Imperative

In meinem Beitrag "Der Software-Handwerker" habe ich das Buch "Software Craftsmanship - The New Imperative" von Pete McBreen schon kurz erwähnt, jetzt bin ich endlich auch dazu gekommen es zu lesen.




Im ersten Teil des Buches geht Pete auf die Ursprünge von Software Engineering ein und wofür es entworfen wurde. Mit einem kurzen Umweg über "good Enough Software" stellt er dann in Frage ob Software Engineering die richtige Metapher für die allgemeine Softwareentwicklung und die zumeist anzutreffende Anwendungsentwicklung ist.
Auf der Suche nach einer besseren Metapher zieht er dann parallelen zum Handwerk und vergleicht auch die Softwareentwicklung mit dem traditionellen Handwerk. Um dann im zweiten Teil weiter auf Software Craftsmanship einzugehen.

Gerade die Erläuterungen zum Software Engineering und dessen Geschichte hat mir noch mal die Augen geöffnet, woher manche seltsamen Anforderungen an zu erstellende Artefakte, einzuhaltende Prozesse oder auch Lerninhalte kommen. Das diese aber nur in einem bestimmten und seltenen Projektkonext Sinn machen wird dabei vergessen oder verschwiegen.

Im dritten Teil geht Pete dann auf die Auswirkungen von Software Crafstmanship nach seiner Vorstellung ein. Dabei beschreibt er sowohl die Beziehung zwischen Anwender und Craftsman als auch die positiven Auswirkungen dieser andersartigen Beziehung auf die Qualität der Software und des Kundennutzens.
Vieles davon kommt demjeniger, der sich heute mit der agilen Softwareentwicklung beschäftigt sicher bekannt vor. Neben einem kurzen Kapitel zum Management von Software Craftsman und der anderen Bedeutung des Managers in so einem Team geht er dann auf den Weg ein, den jemand beschreiten sollte um ein Meister im Software Handwerk zu werden.
Er stellt sich dort einen Weg wie bei dem traditionellen Handwerksberufen vom Lehrling über den Gesellen, welcher auch mit wechselnden Meistern arbeitet zum Meister vor.

Mit Blick auf das heutige Ausbildungssystem von Softwareentwicklern in Deutschland, kann ich dieses Vorgehen nur begrüßen, allerdings benötigt man in den Firmen auch die Strukturen dafür.

Im vierten Teil rückt McBreen dann Software Engineering an die richtige stelle in seinem System und stellt dar, wo es angebracht ist und auch was wir daraus lernen können.

Zum Schluß stellt Pete dann dar wie ein Projekt mit Software Craftsman gestaffed und durchgeführt werden könnte. Dabei geht er auch darauf ein wie man Software entwickelt, welche Wartbar ist und das auch in Zukunft.

Im ganzen Buch liegt immer wieder die Betonung auf der Verantwortung, welche ein Software Handwerksmeister für jede von ihm erstellte Software und für seine Lehrlinge und Kunden übernimmt.

Beim Lesen ist in mir die Vision eines Softwareunternehmens im Handwerkers sinne gewachsen und der Wunsch so zu arbeiten. Aber auch die Frage ob die Kunden bereit sind, sich da drauf einzulassen und für die Qualität ihren Preis zu zahlen.


So und da mich das Buch so inspiriert hat und ich die wertvollen Ideen nicht im Regal nicht verstauben lassen  möchte, habe ich es gerade in einen Briefumschlag gesteckt und auf die Reise geschickt...


Kommentare

  1. Schöne Zusammenfassung. Das FETT geschriebene Wort trifft es auf den Punkt. - Wollen wir wirklich Verantwortung tragen?

    AntwortenLöschen

Kommentar posten

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte.

Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen verteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität.

Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus:

Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit.

Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist.
(Was nun was bedingt, lass ich mal dahingestellt)

Dadurch haben sich natürlich auch die Struktur…

Speed Temenos auf dem AgileDay der JAX

Letzte Woche hatte ich die Gelegenheit auf dem AgileDay der JAX zu sein. Neben Vorträgen am Vormittag mit Beiträgen zu Retrospektiven agile in Konzernen sowie einer spezifischen Implementierung in einem Unternehmen stand nach der Mittagspause ein Speed Temenos mit Olaf Lewitz und Christine Neidhardt auf dem Programm. Zur Unterstützung hatten sie sich Unterstützung über die Softwerkskammer organisiert, so dass die Anwesenden von insgesamt 20 Facilitatoren betreut wurden.

Bei Temenos handelt es sich um einen "geschützten Raum" in dem Menschen Offenheit und Vertrauen erleben können. Das Speed Temenos mit seinen 3 Phasen, in welchen es um die Persönliche (Berufliche) Vergangenheit, den Ist-Zustand und die Vision für die Zukunft geht hilft über Geschichten erzählen, sich selbst zu reflektieren und Gemeinsamkeiten in der Gruppe zu entdecken. Details sind auf http://trusttemenos.de/ viel besser erklärt als ich es hier kann.

Ich hatte Temenos mit Olaf bereits auf der Play4Agile 201…