Die Softwareentwicklung hat ein neues Manifest, das Manifesto for Software Craftsmanship:
Nach dem Manifesto for Agile Software Development [dt.] meint "man" offensichtlich, noch einen Schritt weitergehen zu müssen. Die "Software-Handwerker" nehmen den Ball der Agilisten auf und schlagen ihn bewusst zurück. Die "linke Seite" ihrer Grundsätze (z.B. "working software") entspricht der "linken Seite" bei den Agilisten. So entsteht nun eine dreistufige Wertehierarchie:
| Prä-Agil | Agil | Handwerklich/Post-Agil |
| Ausführliche Dokumentation | Funktionierende Software | Handwerklich gute Software |
| Befolgen eines festgelegten Plans | Mut und Offenheit für Änderungen | Stetiger Wertzuwachs |
| Prozesse und Werkzeuge | Individuen und Interaktionen | Professionelle Gemeinschaft |
| Vertragsverhandlungen | Stetige Zusammenarbeit mit dem Kunden | Produktive Partnerschaft |
Früher war der Fokus also z.B. auf ausführlicher Dokumentation. Darüber haben die Agilisten funktionierende Software gesetzt: Was nützt die beste Dokumentation, wenn am Ende die Software nicht befriedigt? Und darüber setzen nun die "Software-Handwerker" wiederum handwerklich gute Software. Denn was nützt funktionierende Software, die zwar läuft, aber nur zusammengezimmert ist und bei der ersten Belastungsprobe Probleme macht?
Im Craftsmanship-Manifest heißt es zwar "but also" statt "over" wie im Agile-Manifest, d.h. die handwerklichen Werte stehen nicht unbedingt höher als die agilen. Doch letztlich ist das eine Feinheit, denke ich. Wenn über den Grundsätzen der Software-Handwerker "Raising the bar" steht, setzen sie ihre Werte höher als die der Agilisten an, weil sie den umfassendsten Anspruch formulieren:
Das hört sich gut an. In Zeiten, da Softwarequalität schon für tot erklärt wird, ist jede Bemühung um mehr Qualität - denn um nichts anderes geht es den Software-Handwerkern - zu begrüßen.
Und dennoch... Irgendwie mag ich mich nicht vorbehaltlos über diese Form "manifestierter Softwareentwicklung" freuen. Warum? Ich glaube, es liegt an zweierlei:
- Die Form des Manifestes hat für mich gerade auch durch die direkte Bezugnahme auf das agile Manifest einen Beigeschmack. Da schwingt für mich Me-Too-Denken gemischt mit Neid und Kränkung und Hang zur Theatralik mit. Für mein Empfinden sind die Kopie der Form und die Bezugnahme daher kontraproduktiv trotz allem "but also" stat "over".
- Der Inhalt des Handwerker-Manifestes verliert aus meiner Sicht bei allem Willen zum Gegenteil den Kontakt zur Hauptperson: dem Kunden. Als Kunde interessiere ich mich nicht dafür, ob ein Softwareentwickler eine Handwerker- oder Ingenieursattitüde hat. Er soll gefälligst gute Software abliefern. Wie er das macht... egal. Er hat es schließlich gelernt. Oder? Folgt man aber den Diskussionen in der amerikanischen Software-Craftsmanship Gruppe, dann geht es eher um das "rechte Leben als Handwerker" als um Wege zu mehr Kundenzufriedenheit. Erste Softwareentwickler sind sogar schon zusammengezogen. Pair Programming scheint nun nicht mehr zu reichen.
So liegt für mich die Qualität des neues Manifests deutlich hinter der seines Vorgängers. Die Agilisten haben in ihren Grundsätze Aussagen darüber gemacht, was ihrer Meinung nach bessere Software bzw. einen besseren Produktionsprozess ausmacht: funktionierende Software statt "Gerede über Software", die Fähigkeit des Teams zum Umgang mit der Realität häufiger Änderungswünsche, flüssige Kommunikation im Team, enger Kontakt zum Kunden. Das ist knackig. Das lässt sich in seiner Effektivität messen.
Die Software-Handwerker hingegen formulieren schwammig. Sie werfen Fragen auf, wo angesichts lauter Klagen über die Softwarequalität konkrete Antworten nötig wären:
- "Handwerklich gute Software" klingt gut - aber wie lässt sich die handwerkliche Qualität messen? "Funktionierende Software" ist demgegenüber leicht erkennbar.
- "Stetiger Wertzuwachs" bei der Software ist eine gute Sache - aber wie geht das über eine agile Praktik wie das Scrum Backlog hinaus, bei dem der Kunde jederzeit selbst bestimmt, was für ihn wertvoll und daher als nächstes zu realisieren ist? Die agile Offenheit für Änderungen steht im Gegensatz zu Planbefolgungswahn. Der Nutzen, den Agilität behauptet, ist klar zu erkennen. Aber "Wertzuwachs" ist demgegenüber schwach.
- Was bringt eine "Professionelle Gemeinschaft" dem Kunden? Oder ersteinmal: Wer ist überhaupt Mitglied in der Gemeinschaft? Die Softwareentwickler unter sich? Oder das Team zusammen mit dem Kunden? Wo die Agilisten den Menschen ins Bild holen, addiert aus meiner Sicht die "community of professionals" nichts hinzu. Jedenfalls nichts, was erstens messbaren Vorteil böte oder zumindest für den Kunden verständlich wäre.
- Und schließlich die Frage, was an einer "produktiven Partnerschaft" neu ist? Das agile Manifest formuliert wieder klar einen Gegenentwurf: früher verschanzen hinter einmal abgeschlossenen Verträgen, heute stetige Kommunikation. Partnerschaft ist dazu kein Gegensatz und auch kein großer Schritt voran. Allemal, weil Partnerschaft niemandem aufgezwungen werden kann. Will der Kunde ein Partner sein? Die Agilisten lassen die Frage unbeantwortet und begnügen sich mit Realistischerem: kommunikativ engere Kopplung.
Allesinallem empfinde ich also das neueste Manifest der Softwareentwicklung als gut gewollt - aber zu kurz gesprungen. Eine Not zur Herausforderung der Agilitätsbewegung bestand nicht. Aber wenn schon Herausforderung, dann bitte auch "Butter bei die Fische" und nicht Herumgeeiere.
Bemühungen um mehr Softwarequalität und mehr Professionalität in der Softwareentwicklungen sind wichtig. Es ist höchste Zeit dafür. Clean Code Developer soll da nicht allein stehen. Die Software-Craftsmanship-Bewegung ist ja auch schon älter und will im Grunde dasselbe. Eigentlich. Nicht umsonst ist Robert C. Martin Teil beider Schnittmenge. Aber es ist schade, wenn eine Bemühung sich in romantischen Vorstellungen einer Handwerkerzunft ergeht und dann als weit sichtbare öffentliche Geste nur ein Remake eines Erfolgsschlagers zustande bringt.
6 Kommentare:
Hallo Ralf,
schönen Dank für das Posting. Ich kann deinen Ärger nicht ganz teilen, denn die Prinzipen des neuen Manifests zeigen doch nur, dass die agilen Prinzipen einer Reihe von Softwareentwicklern nicht reichen. Sie können sich nicht mit "Individuum" identifizieren, sie wollen eben "Professionals" sein. Sie wollen produktive Handwerker sein und eher das Wort "Zuwachs" statt "Iteration" verwenden, dann lassen wir sie. Da muss man doch nicht gleich "schimpfen" ;).
Ich denke, dass das handwerkliche Manifest der Beginn einer Reihe von Erweiterung sein wird, die dem agilen Manifest hinzugefügt werden. Und so werden sich die agilen Softwareentwicklungsmethoden immer wieder neu erfinden und vor allem verbessern.
Prinzip 2 : "Mut und Offenheit für Änderungen."
@Agile Ära: Habe ich mich geärgert? Hm... nö, nicht wirklich. Ich fühle mich ja nicht persönlich betroffen. Eher finde ich es schade und habe mich gewundert.
Natürlich lasse ich die Softwarehandwerker. Ich schimpfe nicht. Ich schüttle nur meinen Kopf öffentlich.
Da ist ja guter Wille dahinter. Nur finde ich die Form verfehlt - und damit kontraproduktiv.
Die agilen Methoden sollen gern weiterentwickelt, das Agile Manifest gern erweitert werden. Kein Problem. Kann das aber nicht weniger konfrontativ geschehen? Kann es nicht mit mehr Substanz geschehen.
Ja, da reibe ich mich an den Handwerkern: sie sind mir zu substanzfrei. Wie in meinem Posting erklärt, sehe ich den Hub nicht, den sie leisten. Was addieren sie außer einem diffusen Gefühl, dass irgendwas anders gemacht werden sollte?
-Ralf
Agile software development ist ja nicht schlecht, garantiert aber nicht, dass zum Beispiel eine professionelle "Standardsoftware" den realen Bedürfnisse der Anwender bestens erfüllt:
Sollte immer nur nach der Funktionsbeschreibung bzw. Spezifikation entwickelt werden, dann ist das Risiko groß, eine Anwendung auszuliefern, die Mängel ausweist. Denn niemand kann garantieren dass die Specs fehlerfrei/optimal seien...
Manifest for software craftsmanship = gesunder Menschen- und Business-Verstand + Ziel-gerichtete Kunstfertigkeit
Oder so... ;)
Hallo Ralf,
ich gebe dir Recht, wenn du sagst, dass die Substanz fehlt.
Für mich klingt es aber eher noch nach einem Hilferuf, denn offensichtlich sind die agilen Prinzipien nicht verständlich genug - was kann man daran nicht verstehen? -, so dass einzelne ihre eigenen Prinzipien hinzufügen möchten.
Ich selbst habe es mit Kollegen zu tun, die eher den Handwerkerprinzipien folgen, als die agilen umzusetzen. Es muss also noch ein wenig Zeit ins Land gehen, damit die Substanz der agilen Prinzipien von allen entdeckt wird. Und bis es soweit ist, können wir schon die nächsten Schritte machen.
@Loïs
Keine Entwicklungsmethodik dieser Welt kann garantieren, dass die Software die Bedürfnisse erfüllt. Es sind die Individuen, die aus Eigenverantwortung und mit Anforderungen Software entwickeln, die funktioniert und das im Rahmen der Anforderungen. Dabei müssen sie befähigt sein auf die Änderungen durch die Businessanalysten oder Kunden zu reagieren. Bis hier hin ist kein Aspekt der craftsmnship Prinzipien aufgeführt worden. Ich denke das Agile Manifest reicht aus. Es könnte in Teilen konkretisiert werden, aber als Rahmen reicht es aus.
@Agile Ära:
cit.: ...das Agile Manifest reicht aus...
im Prinzip fast aber in der Tat nicht ganz (IMHO).
Die Anforderungen (wer auch immer sie formuliert haben mag) können meistens nicht alles "vorsehen", sei es weil einiges erst zum einem späteren Zeitpunkt klar wird oder auch weil die Spezifikationen "zu einfach" formuliert wurden.
Wirtschaftlichkeit !
Entwickler die "Aufträge" erfüllen müssen, kann man nicht aufbürden die "Lücken" einer Spezifikation umsonst zu füllen.
Andererseits, das Craftsmanship Manifest beteuert die Notwendigkeit, diese Lücken zu füllen. Und zwar in Zusammenarbeit mit dem Auftraggeber. Das führt oft zu kostenpflichtigen "Erweiterungen" der Specs.
Der Entwickler hätte es ja auf die ursprüngliche Specs belassen und dennoch agil bleiben können: solange die Software nicht "nicht funktioniert". Das Ergebnis wäre im Sinne der Spezifikation in Ordnung.
Wenn sich aber der Entwickler das Manifest zu Herzen nimmt, dann ist das Resultat doch besser: für alle Beteiligten.
Beispiel:
Die Spezifikation enthält keine Informationen über das Kontextmenü eines Edit-Feldes.
a) Die agile Entwicklung würde vielleicht dafür sorgen, dass "Cut, Copy, Paste" implementiert wird.
=> Das Ergebnis ist in Ordnung !
b) Das Craftsmanship Manifest sieht vor, dass der Entwickler den Kunden darauf hinweißt welche zusätzliche, sinnvolle Menüpunkte hinzugefügt werden sollten. Dies im fachlichen Kontext der Anwendung.
=> bessere Software als ursprünglich geplant
=> Mehrwert
=> fachlich stimmig
=> konstruktiv
Zumindest ist es mein Verständnis des Manifestes :)
@Loïs
Leider kann ich dir in keinster Weise Recht geben, denn das Crafmanship Manifest beschreibt mit keinem Wort die Messbarkeit der Prinzipien. Es spezialisiert nicht, es fügt generealisierte Werte hinzu. Diese Werte sind gut, bringen uns aber nicht weiter.
Zu deinem Beispiel muss ich sagen, dass es an den Fähigkeiten des Requirement Engineers liegt die Wünsche des Kunden und Leistungen des zu erstellenden Systems zu finden. Wir können doch kein Manifest als schützendes Schild vor uns her tragen um uns im Problemfall darauf zu berufen.
Ich denke, dass ich nichts falsches sage, wenn ich behaupte, dass nicht das Manifest die Produkte erstellt.
Kommentar veröffentlichen