Von Startup-Krautern lernen

Crowdfunfing ist in. Ich habe auch schon mehrfach gesponsort, gefundet, gespendet. Es ist einfach schön, motivierten Menschen unkompliziert ein bisschen helfen zu können - wenn mich die Idee begeistert.

So war es auch bei den Krautreportern. Ihre Vision hat mir in Zeiten des hypebasierten Einheitsjournalismus und der undurchsichtigen Verbindungen zwischen Medienmachern und Institutionen angesprochen:

Krautreporter ist ein tägliches Magazin für die Geschichten hinter den Nachrichten. Werbefrei, gemacht für das Internet, gegründet von seinen Lesern.

Jeden Tag mit vier ausführlichen, möglichst multimedialen Beiträgen von tollen Autoren. Emotional, relevant, journalistisch. In enger Zusammenarbeit mit unseren Mitgliedern. Auf einer modernen, leicht zu bedienenden Seite.

Das war kurz vor Kampagnenschluss im Juni 2014.

Also habe ich gesponsort - und das Kampagnenziel wurde erreicht. Naja, nicht allein durch meinen Sponsorenbeitrag ;-), aber ein kleinwenig habe auch ich dazu beigetragen. Das war ein schönes Gefühl. Und ich habe mich gefreut, bald engagierten, ehrlichen Journalismus zu genießen.

Doch seitdem... nichts. Oder fast nichts. Knapp eine Woche nach Fundingschluss schreiben die Krautreporter in ihrem Blog nämlich etwas. Nur was?

Man kann es nicht lesen. Es ist mit einem Passwort geschützt. WTF!

Außerdem erreicht die Email mit dem Passwort nicht alle Unterstützer. WTF!

Wenn man dann jedoch irgendwann den Zugang zu diesem "Geheimpapier" hat, dann liest man da von einem Plan. Der enthält wiederum einen Plan, nämlich für eine Software. Und noch einen Plan, einen Redaktionsplan. Und man liest von Verträgen die abzuschließen sind, einer Genossenschaft, die zu gründen ist, Büros die zu suchen sind usw. Lesernutzenstifend ist das alles nicht. WTF!

Wahrlich top secret Informationen. Gut, dass man das passwortgeschützt ins Web stellt und das Passwort eher nur auf Nachfrage mitteilt.

Dann im Juli aber ein nächstes Lebenszeichen. Dieses Mal ein öffentliches. Auch schön.

Aha, mit Hochdruck wird gearbeitet. Weiterhin natürlich im Verborgenen. Kenne ich irgendwoher solche Aussage. Ein Muster der Softwareentwicklung abgeschaut, scheint es ;-) Dazu noch ein Versprechen: Eine exklusive Beta-Phase für Mitglieder (dazu zähle ich auch mich als Sponsor) ab September 2014.

Nun ist es jedoch schon fast Oktober. Von einer Beta-Phase habe ich bisher nichts gehört. Auch berichtet das Blog seit Juli nichts mehr über den Fortgang der Hochdruckarbeit. WTF!

So nicht!

Leute, das macht keinen Spaß. So funktioniert doch keine Gründung im Jahr 2014. Haben die Krautreporter in den letzten Jahren soviel schreiben müssen, dass sie keine Zeit zum Lesen hatten? Zum Beispiel Bücher wie Lean Startup oder Kopf schlägt Kapital oder ReWork?

Eine Idee mit Crowdfunding statt über Banken zu finanzieren, ist ein erster Schritt in die digitale Welt. Schön, dass Journalisten sich das trauen.

Aber es gehört schon etwas mehr dazu, um auch in der digitalen Welt dann anzukommen. Wer es geschafft hat, Vertrauen aufzubauen und auch noch Geld einzusammeln, der darf sich nicht zurücklehnen und meinen, damit sei dem 21. Jahrhundert Genüge getan.

Wie gewonnen, so zerronnen - das gilt ganz besonders für Vertrauen. Umso mehr, als dass die versprochene Dienstleistung selbst mit Vertrauen zu tun hat.

Mein Vertrauen jedenfalls ist im Grunde verschwunden. Wie denn auch nicht? Was habe ich bekommen für mein Geld? Nichts. Unregelmäßige Blogbeiträge ohne Relevanz, dazu nicht eingehaltene Versprechen. WTF!

Das ist das Gegenteil von dem Journalismus, den die Krautreporter versprochen haben.

Aber so!

Ich will nicht zuviel spekulieren, doch es drängt sich mir der Verdacht auf: Selbst die motiviertesten Journalisten "alter Schule" stecken so tief im traditionellen journalistischen System, dass sie es schwer haben, sich modern zu bewegen.

Ihre Sorgfalt im Journalismus, ihre Liebe zur Recherche, zum Detail... das passt womöglich nicht zu dem, was der Markt draußen eben auch erwartet: Transparenz und Geschwindigkeit.

Transparenz

Guter Journalismus enthüllt. Nur sollten die Krautreporter das auch auf sich selbst beziehen. Was soll eine geheime Blogbotschaft? Was ich als Sponsor oder auch nur Interessierter möchte, das ist Offenheit, Ehrlichkeit. Kontinuierlich. Proaktiv. Über das, was bei den Krautreportern passiert.

Dafür gibt es Blogs, dafür gibt es Twitter, Facebook, Newsletter. Insbesondere in Phasen, wenn womöglich tatsächlich noch nicht der primäre Nutzen (hier: Artikel) geliefert wird.

Sobald die Produktion begonnen hat, urteile ich anhand der Produkte. Vorher möchte ich heutzutage und insbesondere, wenn da jemand die Crowd bemüht, auf dem Laufenden darüber gehalten werden, wie sich der Fortschritt auf dem Weg zur Produktion gestaltet.

Wo ist die Enthüllung der Krautreporter? Warum gibt es keinen Hintergrundbericht über das Geschäftsmodell, das Eigentumsmodell, die Arbeitsweise? Wo ist die Home Story - oder besser: Office Story - über die Redaktion? Wann gibt es eine Reportage über die Entwicklung einer zeitgemäßen Redaktion? Natürlich in zeitmäßer Form: live! Mit Foto, Video, Tonaufnahme, Text in Kombination.

Das ist doch kein technisches Hexenwerk. Dazu reicht ein Blog. Das gibt es schon. Oder auch noch ein Newsletter gelegentlich. Den gibt es auch schon. (Sagt man, denn erhalten habe ich noch keinen.)

Aber nein. Die Journalisten geben sich intransparent und technisch unwillig bis inkompetent. WTF!

Transparenz schafft und erhält Vertrauen. Wer Geld eingesammelt hat (oder noch etwas dazuverdienen möchte), tut gut daran, den Vertrauensaufbau nicht aus den Augen zu verlieren.

Die Krautreporter sind dafür leider kein gutes Beispiel.

Ein viel besseres ist Circuit Scribe. Die Idee dort: Elektronische Schaltkreise mit einem Stift auf Papier malen.

So ein Produkt marktreif zu entwickeln, dauert natürlich. Es war also nicht zu erwarten, dass nach Kampagnenende bald der Stift schon im Postkasten landet.

Aber Circuit Scribe hat angesichts dessen zeitgemäß gehandelt: Rund alle 14 Tage gibt es ein Update zum Fortschritt. Bisher sind es 28 in knapp 11 Monaten. Das ist Transparenz. Das ist Kommunikation, die Vertrauen aufbaut und erhält. Da behalte ich den Spaß an meinem Sponsorenbeitrag.

Geschwindigkeit

Transparenz ist gut. Doch über alle Transparenz sollte man nicht die Lieferung vergessen. Auch und gerade, wenn man noch nicht 100% sicher sein kann, was eigentlich geliefert werden soll. Das ist bei Software der Fall, das ist aber auch bei den Krautreportern der Fall.

Klar, man startet mit einer Idee. Die hat auch genügend Sponsoren motiviert. Wunderbar. Nur ist die bisher schwammig. Es gibt keinen Prototypen. Es gibt... nichts außer Versprechen.

Weder dient das dem Vertrauenserhalt, noch ist das nützlich für den Leser, und Feedback wird so auch nicht generiert.

Wenn es eine Lehre aus der Agilitätsbewegung oder dem Lean Startup gibt, dann ist es: Liefere in Iterationen. Generiere Feedback. Lerne schnell.

Dieser zentralen Lehre für Unternehmen in Märkten, wo unklar ist, was eigentlich wirklich, wirklich gesucht, gebraucht wird, widersprechen die Krautreporter.

Nicht nur sind sie intransparent, sie haben auch noch keine Kostprobe ihres Könnens geliefert.

Das verstehe ich nicht. Es handelt sich um kein materielles Gut. Wenn Ciruit Scribe Anlaufzeit braucht, wenn Bonnaverde nicht sofort liefern kann, wenn Solar Roadways nicht im Wochenrhythmus Nützliches an jeden Sponsor versendet, dann ist das alles mehr als verständlich.

Aber Krautreporter wie Softwareentwickler können und sollten so schnell wie möglich und so häufig wie möglich liefern. Kleine, feine Inkremente, zu denen die Nutzer Feedback geben können.

Die Krautreporter wollen ja einen digitalen Dienst aufbauen. Dann sollten sie auch die Vorteile der Digitalität nutzen.

Als Sponsor interessiert mich gerade bei dieser Art Produkt nicht, ob es ein Büro gibt, ob schon die perfekte Redaktionssoftware oder der perfekte Website gebaut ist, ob man genossenschaftlich organisiert ist und dergleichen mehr.

Das ist alles nice to have - wenn das Produkt stimmt. Nichts davon ist nämlich eine Bedingung für die Möglichkeit, den versprochenen Qualitätsjournalismus zu liefern.

Wenn am Ende jeden Tag geliefert werden soll, dann erwarte ich natürlich nicht, dass das in Form und Frequenz schon kurz nach Kampagnenende der Fall ist. Aber warum nicht jede Woche ein Artikel? Das müssen keine zehnseitigen Reportagen sein. Sogar work-in-progress würde ich womöglich nehmen. Ganz modern: Nicht immer alles nur in ultimativer Form perfekt am Ende dermaleinst ausliefern wollen, sondern dem Cult of Done folgen. Accept that everything is a draft! Laugh at perfection!

Warum stehen im Blog nicht schon Artikel? Achso, weil man ja nicht für alle Welt transparent sein will. Warum dann aber nicht einen eigenen Newsletter einrichten, mit dem ab und an schon erste Werke verschickt werden? Die können in HTML gesetzt sein. Oder man bietet einen Link zum Download eines perfekt gesetzten PDF an. Oder man macht es gleich digital lesefreundlich und veröffentlicht ePub/mobi Dateien. Achso, da fehlt dann ja noch die essenzielle Kommentarfunktion für die Leser? WTF!

Ist doch egal, wenn es nicht perfekt ist. So ist das bei Experimenten und in der Übergangsphase. Es geht nicht um Perfektion, sondern um Annäherung. Progress over completion sagt dazu das Elastische Manifest. Und reactivity over commitment.

Oder, achso, liegt es vielleicht daran, dass man erst überhaupt mit der Arbeit beginnen wollte, wenn das Fundingziel erreicht wurde? Hm... das wäre schade. Wer keine Vorleistung bringen will, wer nicht geben, aber nehmen will... der macht den Vertrauensaufbau schwer. Geschenke erhalten nicht nur, sondern stiften auch Freundschaft.

Doch auch wenn die Arbeit an Qualitätsartikeln erst nach erfolgreichem Funding begonnen hätte, sollte doch schon das eine andere Ergebnis bis heute zu sehen sein. Nicht jeder Qualitätsartikel braucht doch 3 Monate Arbeit. Das glaube und erwarte ich nicht.

Nun gut: Was die Krautreporter irgendwann mal wirklich als ihr ultimatives Produkt liefern... Wer weiß das schon? Das muss keiner dort wissen. Nein, ich möchte sogar, dass keiner dort meint, dass man das schon wisse. Denn da hätte ich meine Zweifel, dass man der Kraut wirklich zuhörte. Konstant.

Das Produkt der Krautreporter muss sich entwickeln. Vor und in den Augen der Nutzer. So ist das in digitalen Zeiten. Dazu passt aber weder Intransparenz noch Langsamkeit.

Fazit

Aus Fehlern kann man lernen. Schade, dass es gerade ein Projekt ist, das ich gesponsort habe, das nun Fehler macht. Aber so ist das halt mit Investitionen. Nicht alle tragen die Früchte, die man sich erwünscht. Deshalb Investitionen streuen.

In puncto Journalismus setze ich daher nicht nur auf die Krautreporter. Ich "sponsore" auch impulse, agora42, Hohe Luft, die Zeit und brand eins.

Das sind Publikationen in unterschiedlichen Entwicklungsstadien. Ich lese sie, solage sie mir Nutzen bieten. Die Bezahlmodelle sind flexibel genug, dass ich mich frei fühle, ultimatives Feedback durch Kündigung zu geben. Bisher stimmen die Inhalte aber. Also bin ich auch bereit, zu zahlen. Gute Arbeit darf etwas kosten. Die von anderen wie meine.

Dafür möchte ich aber auch, dass man liefert. impulse & Co tun das schon. Die Krautreporter zieren sich noch. Zu lange für meinen Geschmack.

Dass die Menschen dahinter motiviert sind, glaube ich gern. Ich ärgere mich auch nicht über mein Sponsoring. Doch das Ergebnis bleibt mager. Vielleicht können wir ja aber etwas daraus lernen und es besser machen, wenn die Reihe an uns ist, etwas Neues in die Welt zu bringen. Es braucht Transparenz und Geschwindigkeit, um Vertrauen nicht zu verspielen. Hier am eigenen Leib zu erfahren als Kunde des Journalismus. Im Projekt als Lieferant von Software zu beherzigen gegenüber dem Kunden.

PS

Kaum hatte ich diesen Artikel veröffentlicht und getwittert, meldete sich Krautreporter bei mir per Twitter und bat um Kontaktaufnahme zwecks Registrierung zum Newsletter. Das ist aufmerksam. Daraufhin habe ich mir dann nochmal die Postings bei Twitter und Facebook angeschaut. Vielleicht hatte ich ja Transparenz oder Geschwindigkeit übersehen.

Aber nicht wirklich. Auch die verpassten Newsletter haben meinen Eindruck nicht wirklich zerstreuen können. Formulierungen wie “Leider können wir noch keine Details verraten” oder “Mehr dazu bald!” liefern… wieder nichts.

Manchmal ist der Aufbau von Spannung ja spannend. Hier halte ich ihn für kontraproduktiv. Ich will nicht wissen, ob ein Krautreporter von einer Reise zurück ist. Ich will wissen, was er auf der Reise entdeckt hat. Wenn man dazu nichts sagen kann/darf/will, dann lieber schweigen.

Naja, nun warte ich mal ab. Im Oktober soll es wirklich, wirklich bestimmt mit der Betaphase losgehen. Und eine neue Plattform ist dann auch am Start. Es kann also nur besser werden ;-)

Vom Problemtrichter zum Lösungsbaum

Software soll doch einfach nur laufen. Das wünscht sich der Kunde und meint damit, dass sie ein bestimmtes Verhalten zeigen soll. Sie soll gewünschte Funktionalität in bestimmter Qualität bieten, also z.B. rechnen, aber schnell, oder überweisen, aber sicher, oder Videos zeigen, aber für Millionen Benutzer gleichzeitig.

Verhalten wird hergestellt durch Logik. So nenne ich die Summe aus Ausdrücken (Berechnungen, Vergleiche, logische Verknüpfungen, Transformationen mit Sprach- bzw. Plattformmitteln), Kontrollflussanweisungen (if, for, while usw.) und Hardwarezugriffen (mit Plattformmitteln).

Experimentelle Zugabe: Sie können diesen Artikel auch als eBook lesen: ePub, mobi/Kindle

Denken Sie sich Logik quasi als Programmierung auf Assembler-Niveau – allerdings abzüglich Unterprogrammaufrufe.

Damit Software gewünschtes Verhalten zeigt, braucht es keine Unterprogramme, keine Klassen, keine Vererbung, Polymorphie, Interfaces oder was der Sprachgimmicks mehr sind. Unterprogramme kommen später ins Spiel.

Die Aufgabe für uns Entwickler ist also „nur", für ein gestelltes Problem, die passende Logik zu finden. Das hat sich seit den Anfängen der Programmierung nicht geändert.

Und nochmal: Schon Unterprogramme gehören nicht mehr dazu. Sie sind nicht direkt verhaltensrelevant.

Die Frage ist nun: Wie kommt man vom Problem zu dieser Lösung? Ich sehe auf dem Weg dahin zwei Arbeitsphasen:

Phase 1: Probleme in feine Inkremente zermahlen

In der ersten Phase muss das Problem, muss der Anforderungsberg zermahlen werden. Aus einem Monolithen – „Ich will alles!" – muss ein feines Granulat werden. Wir können nicht „Logik herunterschreiben" für ein Lastenheft von 500 Seiten, nicht einmal für eines mit nur einer Seite.

Das ist uns allen auch klar. Wir bemühen uns um Anforderungszerlegung. Da werden Epics formuliert oder Use Cases oder User Stories. Wir versuchen, Software Feature für Feature zu realisieren.

Etwas fehlt mir dabei jedoch. Ich finde diese Zerlegungen oft wenig handfest. Ich finde sie für Kunde wie Programmierer schwer zu begreifen. Nicht weil ihre Sprache zu kompliziert oder die Beschreibungen zu ungenau wären – was natürlich immer der Fall sein kann –, sondern weil ihnen der Bezug zu dem fehlt, was Anwender wie Programmierer am Ende „anfassen".

Wo ist eine User Story in der Benutzeroberfläche einer Software? Keine Ahnung. Kann man mit dem Finger auf einen Use Case zeigen? Ich denke, nicht.

Oder wo ist eine User Story im Code? Keine Ahnung. Kann man mit dem Finger auf einen Use Case zeigen? Eher nicht.

All diese Zerlegungen lösen sich bei der Umsetzung auf, scheint mir. Sie sind irgendwie verschmiert über Benutzeroberfläche wie Codebasis.

Ist das eine gute Sache? Mir scheint, nicht. Denn damit verteilt sich die Logik, die zu ihrer Realisierung geschrieben wird. Wenn dann etwas zu ändern ist, wird es schwer zu lokalisieren, wo Eingriffe nötig sind. Der Widerspruch zum Single Responsibility Principle (SRP) ist vorprogrammiert.

Ich schlage daher eine andere Zerlegung von Problemen vor. Das bedeutet nicht, dass Sie keine User Stories & Co mehr schreiben sollen, wenn Chef/Kunde/Tradition es fordern. Doch Sie sollten dabei nicht stehenbleiben.

Ein für Benutzer wie Programmierer relevantes und greifbares Granulat besteht vielmehr mindestens aus diesen Größeneinheiten:

• Anwendung
• Dialog
• Interaktion
• Feature

Vor ein Problem gestellt, zerlegen wir es zunächst in Anwendungen. Die wiederum zerkleinern wir in Dialoge. Anschließend werden die zu Interaktionen zerrieben, welche wir zu Features zermahlen. Das ist kein linearer Prozess, das geht nicht geradlinig depth-first oder breadth-first. Dennoch ist es systematisch, weil es eben diese klare Hierarchie gibt, durch die wir uns vorarbeiten und in der wir die Ergebnisse verorten können.

Im Grunde geht es darum, das Gesamtproblem durch einen Trichter zu pressen, bis unten nur noch einzelne Features heraustropfen. Das hat natürlich auch mit dem cone of uncertainty zu tun: je größer ein Problem, desto unsicherer, ob und wie es gelöst werden kann.

Findling Anwendung

Eine grobe Zerlegung des Problems „ganzes Softwaresystem" findet zunächst statt in Anwendungen (App). Anwendungen sind separat startbare Programme. Denken Sie „Icon auf Desktop" oder „eigene URL" oder EXE, die man als Batch in einem Terminal-Fenster starten kann.

Eine App ist greifbar für den Anwender. Eine App ist aber auch greifbar für den Entwickler. Der weiß sofort, was er dafür tun muss: ein Projekt für seine Plattform in seiner IDE anlegen. Bei .NET gibt es da z.B. Konsolenprojekt, WinForms-Projekt, WPF-Projekt oder ASP.NET-Projekt. Bei Mono gibt es dann auch noch z.B. Xamarin.Forms für mobile Apps.

Jede App ist kleiner als das Ganze, das der Kunde will – zumindest solange es mehrere Apps gibt. Jede App ist relevant für den Kunden, sie stellt ein Inkrement dar, zu dem er Feedback geben kann. Und gleichzeitig – das ist mir wichtig – ist eine App als Inkrement klar im Code verortbar. Man kann nicht nur am Bildschirm, sondern auch in einem Code-Repository den Finger darauf legen.

Kiesel Dialog

Selbst wenn sich ein Lastenheft in mehrere Apps zerlegen lässt, sind die natürlich immer noch zu groß, als dass man für sie die Logik herunterschreiben könnte. Weitere Zerlegung ist nötig.

Deshalb sind für mich die nächste Granularitätsstufe Dialoge. Jede App erlaubt den Anwendern die Kommunikation durch einen oder mehrere Dialoge. Das können Fenster in einem GUI oder Seiten im Browser oder einfach Eingabeaufforderungen auf der Konsole sein. Oder es können sogar APIs sein, die per HTTP zugänglich sind.

Über Dialoge wird Softwareverhalten getriggert. Anwender „drücken Knöpfe" auf den Dialogen und die Software tut etwas (Funktionalität) hoffentlich effizient genug (Qualität).

Dialoge als kleinere Probleme, als Inkremente sind wieder für den Anwender greifbar – im wahrsten Sinne des Wortes, wenn wir an Touch-Displays denken. Er kann dazu Feedback geben.

Für Programmierer sind Dialoge aber auch greifbar. Dialoge werden gewöhnlich als Klasse (oder Modul) realisiert. Wenn die Anforderung lautet „Wir brauchen einen Anmeldedialog", weiß der Programmierer sofort, dass über einen Designer in seiner IDE eine Klasse anlegen muss.

Die Logik hinter einem Dialog wird kleiner sein als die der ganzen Anwendung sein. Ein Dialog hilft also, das Problem fassbarer, leichter lösbar zu machen. Gleichzeitig ist ein Dialog als Ausgangspunkt für diese Logik einfach im Code zu verorten. Man kann dort wie am Bildschirm den Finger darauf legen.

Sandkorn Interaktion

Doch Dialoge sind immer noch zu groß, um Logik für sie herunterschreiben zu können. Weitere Zerlegung tut Not.

Dialoge fassen nicht nur Anzeigeelemente zusammen, sondern auch das, was ich Interaktionen nenne. So wie in einer zwischenmenschlichen Kommunikation Dialoge aus einzelnen Interaktionen (der eine sagt etwas, die andere antwortet usw.) bestehen, ist das auch bei Software.

Eine Interaktion ist das Verhalten, das Software als Reaktion auf einen Trigger zeigt. Der Anwender gibt Daten in einem Registrierungsdialog ein, dann klickt er einen Button (Trigger) und die Software leistet Funktionalität in gewisser Qualität.

Von solchen Interaktionen kann es pro Dialog viele geben. Sie hängen an Buttons, Menüpunkten, Tastaturkürzeln, Mausbewegungen, Gesten usw.

Interaktionen sind für den Anwender relevant. Zu jeder kann er Feedback geben. Sie stellen Inkremente dar.

Und gleichzeitig sind Interaktionen konkret für den Programmierer. Ihre Entsprechung im Code ist immer eine Funktion. Das kann ein Event-Handler einer Dialogklasse sein oder eine Methode einer Webservice-Klasse.

Funktionen, also Unterprogramme kommen hier ins Spiel als Container für spätere Logik. Sie sind nicht Logik, sondern enthalten und ordnen Logik. Also dienen sie der Wandelbarkeit, nicht Funktionalität oder Qualität.

Zu jeder Interaktion können Eingaben und Ausgaben definiert werden inkl. ggf. darüber hinaus nötiger Zustand (in-memory oder in einer Datenbank) sowie Seiteneffekte.

Die Logik einer Interaktion wird kleiner sein als die eines Dialogs. Interaktionen machen es also leichter, das Problem zu lösen. Gleichzeitig sind die greifbar für Anwender wie Programmierer. Sie lassen sich im Code verorten.

Feinstaub Feature

Was ist ein Feature? Der Begriff „Feature" wird oft verwendet, wir haben ein intuitives Verständnis – doch was genau ist ein Feature?

Meine Definition ist simpel: Ein Feature ist ein Inkrement innerhalb einer Interaktion – das sich im Code mit einer Funktion repräsentieren lässt.

Features sind Softwareeigenschaften, zu denen der Anwender Feedback geben kann. Sie sind für ihn greifbar. Als Aspekte von Interaktionen sind sie nicht notwendig mehr Durchstiche durch die Software, sondern können in unterschiedlicher Tiefe des Verhaltens wirken.

Bei der Registrierung eines Benutzers repräsentiert durch eine Interaktion eines Dialogs einer Anwendung könnte es z.B. diese Features geben:

• Benutzer speichern
• Prüfen, ob Benutzername schon vergeben
• Prüfen, ob Benutzername wohlgeformt
• Fehler melden
• Prüfen, ob Passwort wohlgeformt
• Prüfen, ob Passwortwiederholung dem Passwort entspricht

Für jedes dieser Features ist für den Programmierer wieder sonnenklar, was er tun muss: eine Funktion schreiben.

Features sind mithin greifbar und relevant für Anwender wie Programmierer. Man kann einen Finger darauf legen während der Bedienung, man kann aber auch einen Finger darauf legen im Code.

Synthese

Wie gesagt, Use Cases oder User Stories können ihren Wert haben. Sie beschreiben gewünschtes Verhalten in einer Form, die nichts mit der Realisierung zu tun hat. Bei einer ersten Erkundung der Problemdomäne kann solche Unabhängigkeit nützlich sein, flüssiger zu kommunizieren.

Am Ende jedoch, wenn es darum geht, Software verlässlich zu realisieren, d.h. Problembeschreibungen in Logik-Lösungen zu übersetzen, da glaube ich, dass wir konkreter werden sollten.

Die Lösungsfindung sollte nicht beginnen, ohne ein Lastenheft, ohne Use Cases oder User Stories systematisch auf Apps, Dialoge, Interaktionen und schließlich Features zu mappen. Nur wird inkrementell für den Kunden vorangeschritten und gleichzeitig auch inkrementell im Code. Die Inkremente des Kunden lösen sich nicht mehr auf. Jedes auf allen Granularitätsebenen bleibt im Code als Einstiegspunkt für zukünftige Änderungen erhalten.

Das scheint mir grundlegend für hohe Wandelbarkeit, an deren Anfang Verständlichkeit steht. Und Code, in dem Inkremente sichtbar sind, ist verständlicher als Code, in dem sie aufgelöst sind.

Phase 2: Inkrementelle Probleme lösen

Um es auf den Punkt zu bringen: Ich glaube, dass wir mit dem Codieren, also letztlich dem Schreiben von Logik, nicht beginnen sollten, bevor wir nicht eine klar Vorstellung von mindestens einer Funktion haben. Nur dann lassen sich nämlich Akzeptanzkriterien sauber angeben. Die beantworten vor allem mit Beispielen die Frage: Welcher Input führt unter welchen Bedingungen (Zustand, Ressourcen) zu welchem Output und zu welchen Seiteneffekten?

Im Sinne agilen Vorgehens entspricht so eine Funktion natürlich einem Inkrement. D.h. die Codierung kann erst beginnen, wenn mindestens eine Interaktion aus dem Monolithen Lastenheft herausgepresst wurde. Besser aber noch, wir haben auch die noch weiter zermahlen in einige Features.

Mit Interaktionen und Features könnten wir losgehen. Aber ich glaube, wir sollten noch eine zweite Runde Nachdenken einlegen. Wer nach der Analysephase einfach eine Interaktion oder ein Feature herausgreift und darauf mit TDD einhämmert, um Logik auszutreiben, der arbeitet sicherlich hart – doch nicht notwendig smart.

Denn Analyse ist keine Problemlösung. Durch Analyse wurde nur aus Anforderungen herausgelesen, was ist. Das ist Forschung, geradezu Archäologie. Es wird gehoben, was der Kunde will – soweit er das a priori, d.h. vor der Erfahrung einer Lösung, überhaupt formulieren kann.

Wie jedoch die Lösung aussieht... welche Logik gebraucht wird... das ist nicht klar. Doch das ergibt sich nicht immer so einfach durch Vorlage von Akzeptanzkriterien selbst für ein Feature.

Dazu kommt, dass Features – selbst übersetzt in Funktionen gedacht – nach der Analyse nur lose nebeneinander liegen. Ein Feinstaubhaufen ohne weitere Struktur, selbst wenn er in Interaktionsbeutelchen getrennt gesammelt in Dialogkästen in App-Schränken liegt, ist noch keine Lösung.

Es muss ein Zusammenhang zwischen Features hergestellt werden. Und womöglich muss sogar noch weiter verfeinert werden, wodurch weitere Sub-Features entstehen, die dann wieder einen Zusammenhang brauchen.

Neben der Analyse, dem Erkennen ist deshalb noch Entwurf nötig. Das klein, fein, feinst zermahlene Problem muss im Rahmen einer Lösung wieder zu einem Ganzen zusammengesteckt werden. Features verweisen auf Logik, die zu finden ist. Doch wie hängt die Logik des einen mit der Logik des anderen zusammen?

Ich sehe Lösungen für das feine, inkrementelle Problemgranulat aus zwei Teilen bestehend. Sie beschreiben die Lösung auf unterschiedlichem Abstraktionsniveau: deklarativ, allgemein, grob und imperativ, konkret, detailreich.

Prozesse – Zusammenhang im Fluss

Die obere Ebene von Lösungen ist die der Prozesse. Dort besteht die Lösung auf einer Folge von Lösungsschritten. Was oben noch ungeordnete Aspekte (Features) waren, wird jetzt zu einer Sequenz:

1. Prüfen, ob Benutzername schon vergeben, ggf. Fehler melden
2. Prüfen, ob Benutzername wohlgeformt, ggf. Fehler melden
3. Prüfen, ob Passwort wohlgeformt, ggf. Fehler melden
4. Prüfen, ob Passwortwiederholung dem Passwort entspricht, ggf. Fehler melden
5. Benutzer speichern

Oder eben zu einem Fluss:

Hier fließt allerdings nicht Kontrolle, sondern es fließen Daten. Deshalb ist dieser Fluss deklarativ. Er zeigt nicht Logik, er zeigt keinen Algorithmus, sondern eben „nur" einen Prozess.

Prozesse als Lösungen auf hoher Abstraktionsebene sind einfacher zu finden als Algorithmen. Hier kann man noch „Wünsch dir was" spielen. Man muss nicht genau wissen, wie die Schritte realisiert werden. „Wie geht das mit ‚Benutzer speichern'? Kommt da SQLite oder MongoDb zum Einsatz? Was ist das Datenbankschema?". Das muss nicht klar sein – auch wenn eine Idee davon hilft. Insofern auch bei den Lösungsphasen keine strickte Linearität.

Prozesse bringen Features im Rahmen von Interaktionen in eine Reihenfolge. Es wird sozusagen eine Kausalkette definiert, die vom Trigger bis zur Reaktion der Software über den Dialog reicht. Daten fließen vom Benutzer als Impulse, die Verarbeitungsschritte anstoßen und zu neuen Daten führen, die am Ende wieder beim Benutzer laden.

So existieren „Verhaltensprozesse" auf mehreren Ebenen:

Im Registrierungsdialog (Klasse) wird die Interaktion (Funktion) angestoßen, die aus einem Fluss von Features (Funktion) besteht. Solche hierarchischen Prozesse können viele Ebenen tief sein. Mit ihnen lassen sich die komplexesten Verhalten beschreiben – nicht obwohl, sondern weil sie deklarativ sind und eben nicht alle Details der Logik enthalten.

Prozesse fädeln Features in einen Fluss wie Perlen auf eine Schnur. Der kann eindimensional wie oben sein oder zweidimensional mit mehreren Armen oder dreidimensional durch Schachtelung. Die Summe der Features plus weitere Prozessschritte, auf die man während des Prozessentwurfs zur Lösungsentwicklung kommt, ergeben am Ende das gewünschte Gesamtverhalten im Hinblick auf Funktionalität wie auch Qualität.

Die Lösung ist damit vorhanden – allerdings noch nicht in Form von Code. Ein Prozess ist zunächst nur ein Plan, ein Entwurf. Allerdings ein für die Programmierung sehr geeigneter, weil jeder Prozessschritt in eine Funktion übersetzt werden kann, von der man auch schon weiß, in welchem Zusammenhang sie aufgerufen wird. Und das ist ja, wie oben schon gesagt, die Voraussetzung für die Codierung.

Algorithmen – Abarbeiten in Kontrolle

Ist der Prozess der „Herstellung von Verhalten zur Laufzeit" klar, dann – endlich – geht es an den Code. Denn nun bleibt nur noch die Logik zu finden und zu schreiben. Jetzt ist die unterste Ebene des Zerlegungsbaums erreicht, auf der die Lösung aus Algorithmen und Datenstrukturen besteht.

Jetzt erst ist imperative Programmierung gefragt. Hier geht es um Details. Algorithmische Details und technische Details. Das ist schwierig. Da ist der ganze Softwerker gefragt. Doch zum Glück sind die „Logikhappen" überschaubar. Durch das bisherige Zermahlen ist das Problemgranulat sehr fein geworden, so dass die unterste Ebene der Prozesshierarchie – ich nenne das die Operationen – je Schritt mit einer überschaubaren Anzahl Codezeilen auskommen sollte.

Zumindest sollte die inkrementelle Zerlegung mit anschließendem Prozessentwurf soweit gehen. Sie hören auf, wenn Sie meinen, dass ein Feature bzw. Prozessschritt mit vielleicht maximal einer Bildschirmseite Code in einer Funktion realisiert werden kann.

Aber was, wenn Sie auf eine solch feingranulare Zerlegung nicht kommen? Dann ist das das sichere Zeichen dafür, dass etwas im Argen ist. Entweder sind die Anforderungen noch zu schwammig. Oder Sie verstehen sie noch nicht wirklich – und können deshalb keine gute Vorstellung für eine Lösung entwickeln. Oder Ihnen fehlt technisches Know-how für den rechten Einsatz von API z.B. für die Persistenz oder Security.

Dann können Sie die Lösung noch nicht wirklich fertigstellen. Sie müssen eine Forschungsrunde einlegen, in der Sie Ihre Verständnis-/Wissenslücke irgendwie schließen.

Tun Sie das aber nicht am Produktionscode! Probieren Sie Technologie oder algorithmische Ansätze an Prototypen aus. Bauen Sie sich im Repository eine kleine Sandkiste für diese Zwecke (eigenes Verzeichnis, eigener Branch). Forschung sollte nicht mit Handwerk vermischt werden.

Wenn Sie später mehr wissen, kommen Sie zum Entwurf zurück und treiben ihn weiter, bis die Operationen alle überschaubare Größe haben. Dann und nur dann beginnen Sie mit der Codierung.

Zusammenfassung

Dass zur Softwareentwicklung irgendwie Zerlegung gehört, ist immer schon klar gewesen. Stepwise refinement oder functional decomposition klingeln bei Ihnen sicherlich im Hinterkopf. Das war so grundsätzlich immer richtig – ist mit der Objektorientierung jedoch etwas in Vergessenheit geraten und hat durch die Agilität einen neuen Blickwinkel erhalten.

Die Zerlegung der Anforderung sollte nicht nur Kundenrelevantes produzieren, das iterativ realisiert wird. Nein, ich halte es für ebenso wichtig, diese Inkremente so zu formulieren, dass sie eine Entsprechung im Code finden. Damit ist der Übergang von den Anforderungen in die technische Realisierung, vom SOLL zum IST möglichst bruchlos. Das kann die Verständlichkeit und Wandelbarkeit und auch Produktivität nur beflügeln.

Dann jedoch nicht stehenbleiben! Wenn die Probleme so klein wie Interaktionen und Features sind, lassen Sie die Tastatur am besten immer noch unterm Monitor. Nehmen Sie sich eine Feature oder eine Interaktion vor und entwerfen Sie die Lösung zunächst, statt sie sofort codieren zu wollen.

Sehen Sie die Lösung dabei auf zwei Abstraktionsebenen: der noch eher konzeptionellen Prozessebene und so spät wie möglich erst auf der konkret algorithmischen. Logik ist im doppelten Sinn das Letzte mit dem Sie sich beschäftigen wollen. Vermeiden Sie es, so lange es geht. Wo die Logik beginnt, wo es um Kontrollfluss und Code geht, wird es ekelig.

Das lässt sich nicht vermeiden, denn schließlich muss die Lösung irgendwann laufen. Dazu braucht es Code. Doch zu dem Zeitpunkt wollen Sie vorbereitet sein. Das, was zu codieren ist, sollte in kleine Häppchen portioniert sein. Imperative Programmierung ist schlicht die schwierigste.

„Teile und herrsche" ist also weiterhin das Mittel der Wahl, um Softwareentwicklung in den Griff zu bekommen. Die Frage ist nur, wie teilen? Da sehe ich zwei Sphären mit drei unterschiedlichen grundsätzlichen Ebenen:

• Die Sphäre der Inkremente. Hier geht es um Probleme. Da muss zermahlen werden.
• Die Sphäre der Funktionen. Hier geht es um die Lösungen. Da muss synthetisiert und realisiert werden.

Das Ergebnis der Problemzerlegung sind so fein geschnittene Probleme, dass jedes in eine Funktion übersetzt werden kann. Dafür können Akzeptanzkriterien festgelegt werden. Aber diese Funktionen müssen zu deklarativen Lösungen zusammengefügt und dann ausgefleischt werden. Das sind die Ebenen der Prozesse und Algorithmen.

Das ist nicht die functional decomposition von früher. Es ist anders, weil der Ausgangspunkt Inkremente sind. Es ist anders, weil Prozesse deklarativ und datenflussorientiert sind. Die Kontrollflüsse, die Algorithmen der functional decomposition sind eingehegt in kleine „Bläschen" ganz am unteren Ende der Zerlegungshierarchie. Auf keiner anderen Ebene gibt es Logik. Es gibt keine funktionalen Abhängigkeiten mehr. Das macht das Resultat sauber.

Wie kommen Sie dahin? Auch wenn die Zerlegung sehr geradlinig aussieht, läuft die Entwicklung wie ein Jojo über die Hierarchie hoch und runter. Breadth-first wechselt sich mit depth-first ab. Auf top-down folgt bottom-up.

Das Ziel ist jedoch klar: die feingranulare Zerlegung von Anforderungen und Entwurf nach diesem grundsätzlichen Schema. Problem und Lösung gehen in einander über.

Für mich funktioniert das seit Jahren gut und mit jedem Tag noch besser. Was früher irgendwie vielleicht früher oder später klappte und ansonsten holprig lief, ist nur systematisch und klar. Ich lasse mich nicht mehr von Dogmen ablenken („Agilität muss so und so laufen", „Objektorientierung muss so und so aussehen"). Es zählt, was zügig zu einem verständlichen und wandelbaren Resultat führt.

Ich kann Ihnen diese Sichtweise nur ans Herz legen.