Manifestierte Softwareentwicklung [OOP 2009]

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.

Getting Things Done - ganz anders und ganz einfach [OOP 2009]

Ja, auch ich habe den Zeitmanagement-Klassiker "Getting Things Done" ("Wie ich die Dinge geregelt kriege") von David Allen gelesen. Und ich habe daraus auch etwas gelernt:

1. Habe einen (!) Platz, an dem du alle Aufgaben bzw. Hinweise darauf, sammelst.
2. Nutze diesen Platz konsequent und regelmäßig, um die nächste Aufgabe "abzuholen" bzw. zukünftige Aufgaben zu hinterlegen.
3. Erledige Kleinstaufgaben sofort, plane größere Aufgaben ein.

Ziel dieser Praktik sind mentale Entlastung und Kontrolle. Aufgaben, die man nicht gerade erledigt, sollen die Konzentration im Hier und Jetzt nicht behindern. Äußere Umstände beherrschen nicht, sondern werden durch aktive Planung beherrscht.

That´s it.

Mehr hat mir David Allen nicht gebracht - außer einem schlechten Gewissen, sein ausgefeiltes System nicht genauso ausgefeilt zu benutzen.

Naja, in einem Punkt habe ich es noch angepasst: Wo er empfiehlt, "Abteilungen" für Aufgaben anzulegen, die mit bestimmten Orten oder Gelegenheiten zu tun haben (z.B. "Wenn ich das nächste Mal beim Faxgerät bin"), da nutze ich diese Orte selbst. Habe ich eine Aufgaben, die mit dem Faxgerät oder dem Lebensmitteleinkauf zu tun haben, dann lege ich mir Aufgabenzettel genau dorthin, also zum Faxgerät und zur Wohnungstür (durch die ich zum Einkauf gehe). So "stolpere" ich über meine Aufgaben. Ich muss sie also nicht im Hinterkopf halten.

Ansonsten aber... da grüble ich eher darüber nach, was mich an David Allens gutgemeinten Ratschlägen stört. Und meine Erkenntnis ist inzwischen:

"Getting Things Done" (GTD) ist keine Lösung, sondern ein Symptom.

Das Buch ist ein Symptom für eine Kultur oder auch nur Arbeitshaltung, in der man soviel "auf dem Zettel hat", dass man überhaupt ein ausgefeiltes System braucht, um es zu bewältigen. Es scheint geradezu eine Tugend zu sein, sich soviel aufzuladen, dass man sich nur mit modernen Hilfsmitteln organisieren kann. Eine Aufgabenliste, ein Kalender, eine Wiedervorlagemappe oder auch (im fortgeschrittenen Stadium) eine Assistenz reichen nicht mehr. Nein, es muss ein mehrdimensionales Verwaltungs- und Erinnerungssystem sein.

Seit ich das erkannt habe, geht es mir besser. Ich brauche GTD nicht. Ich brauche nur Mut, mein Leben/meine Arbeit so einfach zu halten, dass ich gar nicht erst in eine organisatorische Überlastungssituation komme. Wenn ich an soviel denken muss, dass ein simpler Kalender und eine Aufgabenliste nicht mehr reichen, dann (!) habe ich ein Problem. Denn dann bin ich sehr wahrscheinlich auch so unter Druck, dass mir als Softwareentwickler schlicht Spielräume fehlen und der Raum für Kreativität begrenzt ist.

Dass GTD mir dann ja gerade helfen würde, diese Räume wieder zu eröffnen durch gute Planung... nun, das halte ich für eine Empfehlung wie "Putz die Zähne öfter, damit die ganzen Süßigkeiten ihnen nicht schaden."  Hier ist die Wurzel des Übels ein übermäßiger Zuckerkonsum, dort ist es eine Hypertrophie des Verantwortungsbewusstseins. Denn nur wer sich für viele Dinge verantwortlich fühlt, der hat auch viele Aufgaben, um diese Dinge geregelt zu kriegen.

Die wahre Lösung des Problems, mit dem sich GTD beschäftigt, lautet daher: Reduktion und Delegation. Weniger tun müssen und/oder andere an der Bewältigung beteiligen.

Wenn die zu regelnden Dinge soviel werden, dass man überhaupt merklich Zeit für ihre Regelung aufwenden muss, wenn also auch die Regelung zu regeln ist... dann ist Gefahr im Verzug. Soviel mal zur Abwechslung ins Stammbuch der ewig geschäftigen Manager geschrieben - zumindest derjenigen, die sich über ihre Aufgabenlast bewusst beklagen oder körperliche/psychische Symptome der Überlastung zeigen.

GTD hat nun einen Platz bei mir im Schrank als Mahnung, mich nicht von den Dingen beherrschen zu lassen und in eine Situation zu kommen, wo ich sie mit "normalen Mitteln" nicht mehr im Griff habe.

So freue ich mich auch, dass es Literatur gibt, hinter denen ein anderes Menschenbild steht und die aus der Regelung von Dingen nicht noch eine weitere, umständlich zu erwerbende Kompetenz machen. Wer bisher an GTD geglaubt hat, der versuche es doch mal zur Abwechslung mit einer anderen Einstellung:

oder ganz simplen Werkzeugen, die sich viel eher auch von Fall zu Fall einsetzen lassen:

Ein bisschen Papier in Form von Notizblock, Notizbuch oder Post-It Zetteln reicht oft in Kombination mit dem Willen zu Überschaubarkeit von Verantwortlichkeiten und Aufgabe von Kontrolle.

Die Dinge geregelt kriegen ist dann ganz einfach. Viel einfacher, als GTD meint.