Im Malkurs – Von Wunsch und Wirklichkeit (Teil 1)

Seit Jahren schon bin ich in diversen Projekten eingebunden. Die Themen reichen von Web2.0 bis ERP, doch eines haben alle gemeinsam, die Art und Weise der Realisierung. Immer wieder ist geplant, konzeptioniert und gesteuert worden. Und immer wieder ist der Termin verpasst worden. Und wieder sind Kunden oder Auftraggeber verärgert. Und wieder stehen die Entwickler wie begossene Pudel da.

Man sollte schon meinen, dass in den letzten 20 Jahren der Wunsch nach mehr Zufriedenheit auf ganzer Linie immer größer geworden ist. Viele Beiträge, so wie dieser, in den Foren oder Blogs suggerieren einem das auch. Insofern verwundert es doch, dass trotz allem noch so viele von Misserfolgen berichten.

Ich möchte mich mit diesem Post auf die Suche  nach einer möglichen Ursache machen, denn ich hab da so einen Verdacht. Doch zunächst die berühmte IST-Aufnahme.

IST (bzw. IST-Analyse)

Der WunschAm Anfang eines jeden Projektes steht die Idee oder vielmehr ein Wunsch, formuliert vom Kunden. Dieser Wunsch kann als Idealbild der Lösung betrachtet werden, aber er ist nicht greifbar. Damit er von Entwicklern erfasst werden kann, wird eine Anforderungsspezifikation geschrieben. Das ist der erste Schritt der Wunschtransformation. Das Idealbild ist zum ersten mal verändert worden und ganz sicher auch schon das erste mal interpretiert worden. Kurz, es ist nicht mehr das Bild, das der Kunde von der Lösung hat. Dumm nur, dass ihm und den anderen Beteiligten das nicht bewusst ist.

Die Anforderungsspezifikation bestimmt ab nun an den Alltag der Entwickler, Architekten, Tester, Product Manager und vielen anderen mehr. Sie bildet die Grundlage für die Formulierung von Aufgabenpaketen und Schätzungen. Bei jeder Umwandlung von Anforderung (vormals Wunsch) zu Aufgabenpaket oder Schätzung entsteht wieder Schwund an der Wunschlösung. Hier ein Beispiel, das jeder nachvollziehen kann:

Wunsch: „Ich möchte, dass einem Mitarbeiter eine Adresse zugeordnet werden kann.“
Anforderung: „Zuordnung von Adressdaten zu einem Mitarbeiter“
Aufgabenpaket: „Speichern von Adressdaten zu einem Mitarbeiter“
Schätzung: 2PT

Das kann jeder nachvollziehen – oder.

So wenig und klein dieses Beispiel auch erscheint, ist es doch Sinnbild für das Große und Ganze, für das eigentliche Problem. Einige stimmen mir jetzt zu, andere wundern sich und sehen kein Problem. Die, die mir zustimmen sind schon oft in dieser Falle gewesen und haben des Pudels Kern entdeckt. Für die Anderen möchte ich mit einer Frage auf das Problem hinweisen: „Aus welchen Daten besteht denn die Adresse?“ Und weil es so schön ist, setze ich noch eine Frage nach um den Fokus zu schärfen: „Sollen die Daten auch geändert werden können?“

Hoffentlich erkennt der ein oder Andere nun den besagten Kern des Problems, es fehlen Informationen. Und ohne diesen Informationen ist das Geschätzte von vornherein ein „magic value“. (Abgesehen davon, dass auch ich kein Verfechter der Schätzungen bin, siehe hier)

Sollten bis hierhin zusammen mit dem Kunden keine Gegenfragen geklärt worden sein, so ist das Projekt ab jetzt zum Scheitern veruteilt und es wurde noch nicht mal eine Zeile Code geschrieben.

Der Schrei

Aaahhhh – es ist Zeit in Panik auszubrechen.

Ja liebe Entwickler, ihr seid nicht Schuld an der Misere, oder doch? Wer hat den vergessen zu fragen, aus welchen Daten die Adresse besteht und ob die Daten geändert, gelöscht oder sogar mehrere Adressen zugeordnet werden sollen? Wer hat vergessen zu fragen, wie das im Prozess der Gesamtlösung von Statten gehen soll, das mit der Adresszuweisung? Ach so, das war der Andere, der die Anforderungsanalyse geschrieben hat, der hat’s vergessen. Gut so, Kopf aus der Schlinge genommen, durchatmen.

Das schmeckt bitter, da bleibt ein komisches Gefühl. Und recht so, es muss ein schlechtes Gewissen bleiben, denn in der Firmenphilosophie steht doch drin, dass ihr ein Team seid und dazu gehört auch:  „Unterstütze deine Kollegen, wo und wann du kannst“ Also wäre es an euch gewesen, dem Anforderungsanalysten die Fragen zu stellen.

SOLL (bzw. Ideal)

Licht am Ende des Tunnels

Wenn ich oben vernünftig geschrieben habe, dann sollte nun erkennbar sein, was ich jetzt als SOLL-Zustand beschreiben möchte.

Da der Kunde in den meisten Fällen gar nichts von der Komplexität von Software weiß, sind wir dazu verpflichtet, ihm dieses bildlich zu machen, indem wir nachfragen, wie er sich seinen Wunsch genau vorstellt. Je mehr wir mit ihm darüber reden, desto mehr Wunschtransformation findet statt. Und was ein richtig guter Nebeneffekt ist, er nimmt Abstand von Killerfeatures, die den Koplexitätsgrad ins unermessliche steigen lassen. Wirklich, das ist so. Und wenn er sich von diesen Features nicht verabschiedet, dann kennt er zumindest die Problemzonen des Systems und ist sich bewusst darüber, dass die Lösung nicht mal eben schnell erstellt ist.

Also ist in einer idealen Welt die Situation so, dass der Kunde seinen Wunsch äußert und das Team, das die Lösung umsetzen soll, ganz eng mit dem Kunden zusammen die Anforderungen hinterfragt und klärt.

Klar, verstanden, los gehts…

Aber nicht doch, das ist zu einfach, denn ich habe noch Hausaufgaben auf. Ich behaupte nämlich, dass es noch etwas gibt, das in dieses ideale Bild eingebaut werden muss. Bisher habe ich nur die Grundierung beschrieben, es fehlen noch Motiv, Bildkomposition, Material und die Farben.

Die nun noch fehlenden Punkte möchte ich in weiteren Posts ausfüllen, doch zunächst soll hierüber diskutiert werden. Unter Umständen habe ich ja eine völlig falsche Sicht auf die aktuelle Projektlage.

~Jan

Advertisements

Ein Bild mit tausend Worten

„Ein Bild sagt mehr als tausend Worte“ heißt es in einem Sprichwort und die meisten werden mir zustimmen. Diejenigen, die nicht zustimmen würden, dürfen dennoch weiterlesen, möglicherweise ändert sich ab hier ihre Einstellung dazu 😉

Vor knapp einem halben Jahr habe ich zusammen mit den Kollegen ein Kanban-Board entwickelt, das den aktuellen Bedürfnissen der Firma entsprach.

Wow wo wow… Halt, was ist ein Kanban-Board?

Na gut, ich hole weiter aus…

Das Kanban-Prinzip

In meiner sehr frühen Vergangenheit als Student, habe ich von einem Produktionsprozess gehört, der von Toyota Anfang der 50er Jahre entwickelt wurde, um die Bestände innerhalb eines Produktionsprozesses zu reduzieren. Das hat viel mit „gebundenem Kapital“, „lean Production“ und anderem BWL-Zeugs zu tun. Das möchte ich hier jetzt nicht auswalzen.

Toyota beschreibt das Prinzip so, dass die einzelnen Fertigungsabschnitte ihre notwendigen Bestände abholt und nicht anliefern lässt, also ein Pull-Prinzip. So reduziert sich zwangsläufig die Durchlaufzeit innerhalb der Produktion und es werden die damals üblichen Staus in der Produktion vermieden.

Schon während des Studiums hatte ich das Gefühl, dass dies ein Prinzip sein könnte, um Software signifikant schneller entwickeln zu können. Noch grün hinter den Ohren und mit naivem Eifer, wendete ich dieses Prinzip bei der Erstellung meiner Diplomarbeit an (Oh Wunder, das Thema hat etwas mit Softwareentwicklung zu tun). Und siehe da, entgegen des damaligen Softwareentwicklungstrends, war ich früher fertig als geplant. (Toll, Schulterklopfen… Nun aber wieder zurück zum Thema bitte)

Kanban in der IT

Einige Jahre später stieß ich bei einer Recherche auf einen Artikel, ich weiß gar nicht mehr genau wo, in dem über einen Entwicklungsprozess geschrieben wurde, der das Kanban-Prinzip aufgriff und für die IT zurechtformulierte. Das ist nötig, da es ja in der IT nun mal keine „Lagerbestände“, sondern nur Code und Features gibt.
Ich war überaus begeistert davon zu lesen, dass Kanban Einzug in die IT hielt. Dummerweise sah ich dann das Datum des Artikels. Es war doch schon einiges vor meinem privaten Diplomexperiment. Ich war also nicht der Erste meiner Art, zu dumm, nichts zum Angeben.

Wiederum einige Zeit später, wurde ich von meinen Vorgesetzten gefragt, welchen Entwicklungsprozess ich verwenden würde um innerhalb der gegebenen Entwicklungsparameter einen besseren „Produktionsdurchsatz“ zu erzielen. Das war meine Stunde. Ich schlug sofort Kanban vor, weil ich wusste, dass dieser Prozess optimal für bestehende Entwicklungen, bei sog, brown fields, anzuwenden ist. Die Argumente gegen SCRUM waren schnell mit Hilfe der Präsentationen von it-agile gefunden und vorgetragen. Was nun noch fehlte, war das …

… Kanban-Board

Kanban-Board

Mit Hilfe diverser Kanban-Dokumentationen war schnell ein Board erstellt, das den ersten Ansprüchen genügen sollte. Wir nahmen uns vor, das Board und auch den Prozess im Laufe der Zeit zu verbessern. Glücklicherweise gibt es das Daily Meeting, sprich jeden Morgen Treffen vor dem Board, so dass die Optimierung binnen kürzester Zeit begann.

Daily Business

Zuerst brauchte man eine extra Bahn für das Daily Business. Ein Berich, in den die Bugs bzw Tickets zur laufenden Anwendung rein kamen. Damit sollte dokumentiert werden, wie anfällig oder auch wie sicher das System läuft. Außerdem konnte dann der Product Owner (PO) die aktuelle Auslastung des Teams sehen.

Testing

Auf dem klassischen Board findet man immer wieder die Spalte für den Entwicklungsschritt „Testen“. Da sieht man dann wie viele Tests gerade durchgeführt werden und welche davon erledigt sind. Das sah in unseren Augen aber eher nach unnützer Information aus, weil unsere Tests voll automatisiert durchgeführt werden. Selbst die Oberflächentests werden mit entsprechenden Frameworks automatisch durchgeführt. Somit sahen wir nicht mehr die Notwendigkeit eine solche Spalte aktiv zu führen. Der Sinn der Spalte „Test“ reduziert sich auf das geplante Prüfen der Features durch einen physischen Tester, der versuchen darf, das System zum Absturz zu bringen. Sprich er führt die sog. Smoketests durch.

Dokumentation am Board

Story Bag

Eines Tages, wir waren wieder in der Laune etwas zu verbessern, stellten wir uns die Frage, warum so viele kleine Zettelchen am Board hängen. Klar, weil viel zu erledigen ist, aber die Frage danach, wohin die Zettelchen gehörten, warf noch mehr Fragezeichen auf.  Bis zu diesem Zeitpunkt versuchten wir immer eine imaginäre horizontale Linie als Grenze zwischen den User Stories zu sehen. Je mehr Tasks aus den User Stories purzelten, desto unübersichtlicher wurde das Board. Es war also nicht die Anzahl der Stories, die einen „Stau“ verursachten, sondern die Struktur des Boards sorgte für Missfallen. Eine Lösung musste her, die durch Zufall schon in meiner Hand lag.

Jedes Daily  wird mit der Sichtung der Begleitpapiere eingeleitet. Darunter befinden sich u.A. die Modelle, Diagramme, Konzeptbeschreibungen usw. usf. „Warum nehmen wir nicht einfach diese Begleitpapiere, splitten sie in die User Stories auf und hängen diese direkt als ‚Story Bag‘ an das Board?“, war die Frage. Gefragt, getan. Der PO schnappt sich die Anforderungsanalyse, schneidet wie gewohnt die Stories heraus, modelliert die Anforderung und hängt sie, nachdem die Story gezogen wurde in die Linie des Work in Process (WIP). Die Modelle werden Teil der User Story, hängen als Dokumentationshilfe immer mit am Board und helfen so zum Verständnis beizutragen.

Sehr coole Sache, denn nun kann das Team die Story vom Board nehmen, die Tasks identifizieren und zusammen mit der Story wieder an das Board hängen. Abgearbeitete Tasks landen wie gewohnt im „Development-Done“, aber die Story selbst bleibt im „Develpoment-In Proc“. So kann man sehr schön verfolgen, wie sich die Anzahl der Tasks reduziert und damit die Sicht auf das Modell frei gibt.

Fazit 1

Egal wie gut der Prozess in den Büchern beschrieben ist, es gibt immer noch Möglichkeiten ihn für die eigenen Zwecke anzupassen. Das sollte man auch tun, denn zum Einen verbessert sich das Verständnis für den Prozess selbst und zum Zweiten entsteht eine Art persönlicher Bindung zum Prozess. Man identifiziert sich damit.

Fazit 2

Durch das dokumentieren der Story in Form eines Modells steigt bei jedem das Verständnis vom Gesamtsystem. Zudem können Querverweise in den Stories besser besprochen werden, wenn die Modelle mit am Board hängen.

 

~Jan

Das erste Mal

DevCon 2011Neulich – ach was sag ich da, es ist doch schon ein wenig her – habe ich mit Mike Bild ein wenig herumgeflachst und wir stellten fest, dass man ja mal bei einer Konferenz als Sprecher auftreten könnte. Er hat das ja schon das ein oder andere Mal gemacht, aber für mich würde es was völlig Neues sein. Da ich mich mit dem Gedanken anfreunden konnte und just in diesem Moment die Anfrage zur DevCon 2011 eintrudelte, habe ich mich kurzerhand zur DevCon angemeldet.

Tja, un nun ist es bald so weit, meinen Gedanken zum Thema Modellierung ist ein Forum geboten. Ich kann versuchen dem geneigten Zuhörer etwas von abstrakter Denke, Stichelein und Mut zum Modellieren näher bringen. Wie James T. Kirk im Film „Treffen der Generationen“ schon sagte,  „das wird sicher ein Spass“.

Also, ich werde am 07.06. in Nürnberg zum Thema Modellierung und Architektur einen Vortrag halten mit dem Titel „Von der Idee zum Modell“. Und jeder ist herzlichst eingeladen, sich meinem, aber auch den anderen Vorträgen anzuschließen.

~Jan

Überholen ohne einzuholen

Dieser Spruch scheint im ersten Moment nicht möglich zu sein, ist er aber doch.

Wie ich in diesem Blog „Mit Fingernägeln…“ beschrieben habe, ist die letzte Instanz der Manager immer die Kündigung. Ich wusste nicht wie schnell mich das einholen würde.

Nun sitze ich ein wenig begossen wie der sprichwörtliche Pudel und weiss nicht so recht, wie ich damit umgehen soll. Ich habe doch nur Qualität eingefordert. Also nichts schlimmes, denke ich. Ich habe doch nur das getan, was jeder Entwickler von seinem Product Owner/Project Manager/und wie sie nicht alle heissen verlangen sollte, Qualität eingefordert. Oder besser gesagt, ich habe Qualität angeboten. Damit kann mir doch nicht vorgeworfen werden, dass ich nicht loyal bin. Oder doch?

Ich habe nur versucht den Traum des Entwicklers wahr werden zu lassen oder besser noch, die Frage nach dem „Was treibt uns an?“ zu beantworten.

Was lerne ich daraus? Man kann von überholten Paradigmen schnell eingeholt werden und muss dann wegen der vermeintlich fehlenden Loyalität das Handtuch werfen.

Edit: Ein paar Tage später… Ich genieße die Sonne im Gesicht und freue mich, den Schritt zum eigenen Chef zu wagen. Ich bin gespannt, wie viel Energie in mir steckt.

~Jan

Mit Fingernägeln über die Tafel

Mit „Iiihhhhhh“ reagieren da die meisten Leute. Und ich freue mich darauf, ich habe nun die ungeteilte Aufmeksamkeit, wenn auch nur kurz. Das sollte aber reichen.

Ring frei

Letztens habe ich einem Tweet geschrieben, in dem ich meinte, dass in der Softwareentwicklung: „…nicht der Anspruch auf Qualität zählt, sondern der Anspruch auf Wettbewerbsfähigkeit„. Nach kurzem hin und her erweiterte ich die Erklärung etwas griffiger, mit den Worten: „Der Anspruch an die Wettbewerbsfähigkeit, zieht den Anspruch der Qualität nach sich„.

Ich erntete etwas Beifall, aber auch kritische Stimmen. Was mich veranlasste diesen Blog-Post zu schreiben, um meinen Gedanke mehr Raum zu geben als nur die 140 Zeichen Twitter Postings.

(Der nun folgende Text hat seinen Ursprung in der Unzufriedenheit der Wiederholung. Etwaige Ähnlichkeiten mit bekannten Situationen ist rein zufällig, macht aber die Umfang der Wiederholung deutlich. Die Metapher der Boxringes wird zu Demonstrationszwecken benutzt und hat nichts mit den Besprechungsräumen der Unternehmen zu tun.)

Die Kontrahenten

In der linken Ecke: Das Management, das ein verkaufbares Produkt zum zahlen der monatlichen Kosten braucht. Die Manager symbolisieren den Anspruch auf Wettbewerbsfähigkeit.

In der rechten Ecke: Die Entwickler, die ein schlechtes Gewissen bekommen, wenn ihr Code nicht wartbar, flexibel und weiteren Attributen der „sauberen Software“ genügen (siehe Clean Code Developer) . Sie symbolisieren den Anspruch auf Qualität.

Nun mag der ein oder andere Leser dazu neigen und behauptet es gäbe da noch mehr. Stimmt, „recht du hast, mein junger Padawan“ [1], sage ich da, denn der überwiegende Teil der Entwickler ist hier noch nicht aufgeführt. Auch wenn es in den letzten (!) Jahren besser geworden ist, gibt es immer noch abertausende Entwickler, deren Anspruch als sirenenhaft beschrieben werden kann. Das sind diejenigen, die Morgens im Büro vor der Tür das Hirn abgeben und abends erst wieder einsetzen. Dazwischen werden Codezeilen produziert, die das Ziel haben, das Produkt für immer an den Entwickler zu binden. Das ist die Gruppe Entwickler, die perfekt zum Manager passen und daher auch der linken Ecke zugeordnet werden sollten.

Ich gebe es hier offen und ehrlich zu, ich gehöre eindeutig in die Ecke der Entwickler mit dem Anspruch auf Qualität.

Runde 1

Der Manager entscheidet sich für ein neues Produkt. Ohne viele Worte formuliert er eine Anforderung. Gerade heraus zielt er direkt auf den Entwickler und verpasst ihm damit einen schweren Schlag. Leicht strauchelnd fasst der Entwickler Mut und geht auf den Manager zu, um mit feinen Worten in die Deckung der Anforderungsanalyse zu gehen. Das trifft den Manger so hart, dass er kurz darüber nachdenkt, das Handtuch werfen zu lassen, um sich einen neuen Gegner von einem anderen Kontinent zu suchen.

Da der Manager diese Situation aber kennt, weicht er dem Entwickler bei der nächsten Anforderungsanalyseparade aus und holt zum „Das ist doch ganz einfach mit Copy und Paste erledigt“-Schlag aus. Der Entwickler ist getroffen. Die Sinne sind benebelt und ein lauter Piepton im Ohr des Entwicklers verhindert, dass weitere Signale im Hirn ankommen. Ein dumpfer Schlag auf die Wange lässt den Entwickler vermuten, dass er der Länge nach hingeschlagen ist.

Da kommt der erlösende Gong.

Rundenpause

Die Trainer und Berater instruieren die Kontrahenten für die nächste Runde. In der Managerecke hört man nur ein leises: „… na siehste, ist doch wie immer. der CP-Punch klappt immer. In der nächsten Runde ist er erledigt“. Doch in der Ecke des Entwicklers ist ein wildes Durcheinander entstanden.

Der Kämpfer selbst ist schon wieder voll auf den Beinen und hoch motiviert. Aber sein Team scheint den selben Schlag abbekommen zu haben. Da meldet sich eine Stimme im Hintergrund und wiederholt mantraartig: „… denke an den heiligen Clean Code, lasse dich nicht ablenken vom Brownfield, arbeite strukturiert, die Anforderungen sind entscheidend, du hast das Recht darauf gute Software abzuliefern…“. Nun erwacht das Team auch wieder aus der Lethargie und scheint sogar die letzten Sekunden vollständig vergessen zu haben.

Mit vollem Einsatz wird der Entwickler für die nächste Runde vorbereitet.

Der Gong ertönt

Runde 2

Der Manager ist schnell in der Mitte der Ringes und öffnet auch schon den Mund für den nächsten „CP-Punch“, aber das war genau das, was der Entwickler erwartete. Er holt aus seiner „überdimensionalen Hosentasche“ [2] die CCD-Argumentbazooka raus und feuert sie direkt auf den Manager ab. Die Begriffe „Evolvierbarkeit“, „Korrektheit“ und „Produktionseffizenz“ zerbarsten an der Brust des Managers und scheinen keinerlei Spuren zu hinterlassen. Doch was ist das? Zwei scheinbar unbedeutende Wörter – sie waren nur Lückenfüller in der Argumentationsgranate – scheinen sich einen Weg direkt in das Hirn des Managers zu bahnen. Nahezu ungehindert dringen „Wettbewerb“ und „Kostenreduzierung“ vor und hinterlassen hässliche Wunden.

Der Manager ist zweigeteilt. Beide Hälften beginnen nun einen wilden Ringkampf und der Entwickler ist außen vor. Die Menge jubelt… Sie jubelt? Welche Menge? Niemand außer den beiden Teams ist in der Halle und am Ring.

Das Team „Entwickler“ packt schon die Sachen ein, der Sportler selbst dreht dem Ringerpärchen den Rücken zu, da gibt es plötzlich einen grellen Blitz und der Entwickler ist nicht mehr an seinen Platz. Das Team „Manager“ hat aus den hinteren Reihen die „Kündigung“ gezündet. Durch den Blitz verwirrt, sind die beiden Hälften des Managers so abgelenkt, dass das Team „Manager“ in der Lage ist, die Hälften widerstandslos zu einem Ganzen zusammen zu fügen.

Was eben noch nach einem Sieg für das Team „Entwickler“ aussah, scheint nun eine saftige Niederlage zu sein.

Der Gong ertönt.

Siegerehrung

Da nun nur noch der Manager im Ring ist. Sieht es so aus, als ob es einen eindeutigen Sieger gibt, doch weit gefehlt. Der Schiedsrichter betritt den Ring und alle halten den Atem an. Es ist der unbeliebteste Schiedsrichter, den sich die Manager je gewünscht hätten, Zeit.

Zeit nimmt den Arm des Managers am Handgelenk fest in den Griff. Der schaut sich hilfesuchend um, aber das Team „Manager“ ist schon längst weg. Er ist nun allein mit Zeit und dem Team „Entwickler“. Der Manager setzt sein wehleidigstes Gesicht auf, an das er sich noch aus seiner Kindheit erinnert und ruft laut „Willst du, dass wir sterm?“[3]. Da reißt Zeit dem Manager den Arm so heftig in die Höhe, dass er sich vom Körper löst.

Blende und aus.

Egal wie groß der Wunsch nach „Schnell-Schnell-Software“ auch ist, früher oder später wird man vom Leben überrollt. Da hilft es auch nicht, wenn die Unbequemen entfernt werden und nur noch die Konformen die Wünsche „einfach mal“ umsetzen. In diesen Zeiten stehen ganz sicher weitere Wettbewerber in den Startlöchern um mit der Dampfwalze des Lebens los zu fahren.

~Jan

— Quellenangaben

[1] Meister Joda aus Star Wars(tm)

[2] Lucas Arts, „Indiana Jones and the Fate of Atlantis“

[3] Die Ärzte, „Jazz ist anders“, Titel: Junge

Die Retusche – EBC im Brownfield

Lange hat es gedauert, dass ich mich an dieses Thema gewagt habe. Nun ist es aber soweit, weil die aktuelle Projektsituation es verlangt.

Ich möchte EBC’s in einem Brownfield Projekt einfügen. Die Schwierigkeit ist das Projekt an sich, das durch seine sehr “interessante” Struktur das anlegen von EBC’s quasi verhindert. Dennoch bin ich der Meinung, das ich das Projekt mit Hilfe von EBC’s verbessern kann und zwar im Bereich der Infrastruktur, respektive dem Logging.

Derzeit existieren viele tausend Programmzeilen im Projekt, die das Logging durchführen und damit den Code “verunreinigen”oder besser vom Wesentlichen der Funktionen ablenken. Mein Plan ist es also mit Hilfe der AOP einen Loggingaspekt zu integrieren, der dann mit EBC Technologie eben diese Aufgabe erfüllt. Nun könnte der ein oder andere meinen: “So ein Quatsch, das ist doch nicht nötig, die traditionelle Herangehensweise ist doch vollkommen ausreichend”. Dem kann ich im Prinzip nichts dagegensetzen, es sei denn ich erwähne die Entkopplung zwischen Aspekt und Logging Framework oder der stark vereinfachten asynchronen Logik. Aber das sind ja Attribute, die in keiner sorgfältig geplanten Software etwas zu suchen haben.

Nein, im Ernst, ich habe vor den Aspekt und den Loggingprozess als EBC’s zu formulieren, damit ich die Vorteile der EBC ausnutzen kann. Auf diese Weise erreiche ich möglicherweise noch etwas anderes: Nebenläufigkeit der Applikationsinfrastruktur. Na mal sehen, wohin das führt.

Istzustand

Zur Verdeutlichung hier mal eine Darstellung des Istzustandes einer beliebigen Datenzugriffsmethode:

Daten laden

  • Daten werden gelesen
    • Falls ein Fehler auftritt wird eine Fehlermeldung erstellt und an einen Logger gesendet, der ihn wegschreibt
  • Daten werden in DTO’s gemappt und zurückgegeben
Sollzustand

An der Stelle des Schrittes “Handle Exception” möchte ich nun statt des berühmten try-catch-Blockes einen Aspekt verwenden, der die gleiche Aufgabe erfüllt, aber den Code nicht verunreinigt.

Handle ExceptionLog ist der Aspekt, der in der Applikation verwendet wird und im Falle einer Exception die Nachricht an den Logger sendet . Diese Kommunikation sollte asynchron geschehen, damit das Logging die Applikation nicht blockiert oder verlangsamt.

Vorgeschichte zur Lösung

Am Anfang stand die Aussage “AOP für das Logging”. Dies wollte ich mit PostSharp umzusetzen, weil ich damit schon seit Jahren herumhantiere. Aber dann kam die Ernüchterung: die Aspekte kann ich auf keiner Platine instanziieren und verdrahten. Das führte dazu, dass ich einen kleinen Ausflug zu  SNAP machte, weil hiermit Aspekte und Instanzen in ein und dem selben DI-Container behandelt werden, …seht selbst:

Lösungsversuch 1: PostSharp Aspekt und die Platine
PostSharp Aspekt + EBC Output
  1. [Serializable]
  2. public class Log : OnMethodBoundaryAspect, ILogAspect
  3. {
  4.     public override void OnException(MethodExecutionArgs args)
  5.     {
  6.         OutExceptionLog(new ExeptionLogMessage(args.Exception)
  7.                                  {
  8.                                      Method = args.Method.Name
  9.                                  });
  10.     }
  11.     public Action<ILogMessage> OutExceptionLog
  12.     {
  13.         get; set;
  14.     }
  15. }
Logger als EBC
  1. public class Logger : ILogger
  2. {
  3.     public void InLogMessage(ILogMessage logMessage)
  4.     {
  5.         System.Diagnostics.Debug.WriteLine(logMessage.ToString());
  6.     }
  7. }
Die Verdrahtung
  1. ObjectFactory.Configure( x => x.For<ILogger>().Use<Logger>());
  2. ObjectFactory.Configure( x => x.For<ILogAspect>().Use<Log>());
  3. ILogger logger = ObjectFactory.GetInstance<ILogger>();
  4. ILogAspect logaspect = ObjectFactory.GetInstance<ILogAspect>();
  5. logaspect.OutExceptionLog = _logger.InLogMessage;

Das sieht alles total einfach aus, ist es auch. Aber wie das so oft ist, der Teufel steckt im Detail, denn der Aspekt wird von PostSharp gesteuert und steht für diese Art der Verdrahtung gar nicht zur Verfügung. Wenn ich also eine neue Instanz zum Zwecke des Verdrahtens erzeuge, verbinde ich nicht wirklich die Pins der Komponenten, die tatsächlich arbeitet, sonder eben einfach nur eine neue Instanz. Der Aspekt sendet also seine Nachricht in das elektrische Nirvana.

Lösungsversuch 2: SNAP und StructureMap

Dieser Versuch scheiterte an der Anforderung im Brownfield zu funktionieren und an der Tatsache, dass ich auch hier nicht auf die tatsächlichen Instanzen der Aspekte zugreifen und damit die Verdrahtung realisieren kann.

Lösungsreview

In beiden Fällen kann ich die arbeitende Instanz nicht mit dem Logger Verdrahten, weil ich keinen Einfluss auf den Instanziierungszeitpunkt habe.

Eine Lösung wäre also ein globaler EventListener – für diesen Gedanken müsste ich mir das Gehirn mit Seife waschen –, der die Events der Aspekte einsammelt und verarbeitet. Das ist aber nicht EBC, das ist unerwartetes Verhalten, das ist meiner Meinung nach nicht Clean Code. Daher muss etwas anderes her: Statische Out Pins. Die sind sehr einfach zu realisieren und darüber hinaus auch noch verständlich.
Was aber schmerzt bei diesem Gedanken? Richtig, das Schlüsselwort “static”. Ich habe einfach zu viele schlechte Erfahrungen mit öffentlichen statischen Methoden oder Feldern gemacht. Nur in diesem Fall scheint es nichts Besseres zu geben, oder?

Erklärungsversuch – Beschönigung

Wenn ich also ein statisches Field am Aspekt habe und damit den EBC Charakter einer Komponente erzeuge, dann kann dies doch nicht so schlecht sein. Zudem passt dies auch in das Konzept der Infrastruktur. Logging gehört zur Infrastruktur, ist ein eigner Concern und kann somit auch als großes Ganzes innerhalb der Applikation existieren. Quasi als globale Komponente, die von allen Seiten die Nachrichten empfängt und verarbeitet.

Wenn nun jemand einen bitteren Geschmack im Mund hat, sollte einen Kommentar zu diesem Thema hinterlassen, denn auch ich bin mit dem statischen Field nicht so glücklich und vielleicht finden wir gemeinsam einen besseren Weg.

Der Lösung

Ich habe mich nun erst einmal für die Lösung Nummer 1 entschieden und verändere nur den Scope des Out Pins von “public Action” auf “public static Action”. Auf diese Weise kann ich Verdrahten und die Nachrichten verarbeiten.

Aspekt mit statischem Out Pin
  1. [Serializable]
  2.     public class Log : OnMethodBoundaryAspect
  3.     {
  4.         public override void OnException(MethodExecutionArgs args)
  5.         {
  6.             OutExceptionLog(new ExeptionLogMessage(args.Exception)
  7.                                      {
  8.                                          Method = args.Method.Name
  9.                                      });
  10.         }
  11.         public static Action<ILogMessage> OutExceptionLog
  12.         {
  13.             get; set;
  14.         }
  15.     }
Verdrahten
  1. ObjectFactory.Configure( x => x.For<ILogger>().Use<Logger>());
  2. ILogger logger = ObjectFactory.GetInstance<ILogger>();
  3. Log.OutExceptionLog = _logger.InLogMessage;

Das sieht schon richtig einfach aus. Wie sich das in der Praxis macht, werde ich nun erst einmal beobachten.

Nachtrag

Oben erwähnte ich noch die asynchrone Verarbeitung. Die baue ich natürlich auch einfach mal eben so ein, wie Ralf Westphal es in seinem Blog  für Asynchrone Kommunikation mit EBC’s beschrieben hat.
Ob ich schon Rx verwende, werde ich auch noch sehen. Heute möchte ich erst einmal das Grundgerüst aufstellen.

~Jan

Ein Bild entsteht – EBC im Web (Teil 3)

Es geht weiter…

Nachdem ich die Systemidee und die Domäne beschrieben habe, soll hier nun das Herzstück der Planung entstehen, die Prozessbeschreibung. Im EBC Konzeptionsprozess werden die einzelnen Aktivitäten und Prozesse schichtweise von einem hohen zu einem niedrigen Abstraktionsniveau beschrieben. Diese Form der Beschreibung spiegelt die Infrastruktur der Applikation wieder. Sie entspricht der Formulierung der White Box Diagramme für Komponenten. Ich bediene mich der grafischen Formen von Aktivitätsdiagrammen, was in der Natur der Sache liegt, wenn man Prozesse, Aktivitäten und Aktionen beschreiben möchte.

Prozesse im Projekt

Der Bezahlprozess bildet die simpelste Sicht auf das System und beschreibt, dass nach der Buchung die Berechtigung für die erweiterten Inhalte erteilt wird.

Bezahlprozess

Eine Sichtebene tiefer befindet sich der gesamte Prozess ‘Produkt buchen’. Jede hier aufgeführte Aktivität wird wiederum als Prozess betrachtet und kann als einzelne Story mit überschaubaren Aufwand umgesetzt werden. Eine kleine Ausnahme nimmt hier die Aktivität ‘Zahlungsart wählen’ ein. Da ich noch nicht genau weiß, wie ich diese Stelle umsetze, habe ich sie vorerst aus der Planung ausgeschlossen.

Produkt buchen

Den Weg verlassen

In diesem Post möchte ich nicht alle Diagramme für jeden Prozessschritt darstellen, weil ich der Meinung bin, dass eine exemplarische Darstellung ausreicht, um das Prinzip zu verstehen.

Abweichung 1: Im Diagramm ‘Produkt buchen’ und der ersten Prozessebene habe ich die für die EBC typischen Pins weggelassen um zu zeigen, dass nicht die Pins wichtig sind um den Prozess zu beschreiben.

Abweichung 2: Auch wenn ich im kommenden Diagramm die Pins schon eingefügt habe, fehlt dennoch ein sehr wichtiges Detail, die Fehlerbehandlung. Sie würde durch Out Pin’s und eine Activity modelliert werden.

Zurück auf den Weg

Exemplarisch stelle ich hier nun den Prozessschritt ‘Rechnungsadresse eingeben’ dar (ohne Fehlerbehandlung).

Rechnungsadresse eingeben

Was wird dargestellt? Wenn der Anwender den Prozess ‘Rechnungsadresse eingeben’ betritt/auslöst/startet, kann er entscheiden, was er zuerst eingibt. Zwischen ‘Vorname eingeben’ bis ‘EMail eingeben’ ist jede Kombination drin. Nach einer fertigen Eingabe wird der Wert oder eine Wertkombination durch Logik validiert. Am Ende des gesamten Prozesses (hier nicht optimal dargestellt) sollen alle Eingaben validiert sein und es kann der Prozess ‘Zahlungsart auswählen’ starten.

Gut, ich denke, dass ich das Prinzip darstellen konnte. Im nächsten Schritt soll es schon um Code gehen. Code, der auch beispielhaft zeigt, wie die Prozesse, Activities und Actions zusammengefügt werden.

Jan

>Ich mach mal ‘ne Auszeit

>Als ich im Sommer mit meiner Frau in Paris war, da dachte ich mir schon, dass eine Stadt mit Tradition und Vergangenheit etwas tolles an sich hat. Man sieht an jeder Straßenecke irgend etwas schönes. Nach drei Tagen war aber genug von Jugendstil und Moderne, es wiederholte sich. Die Sehenswürdigkeiten, die wir uns anschauten waren einfach zu weit verteilt, so dass man Tage brauchte um (fast) alles zu sehen.

Nun bin ich hier im viel zu kleinen Zürich und habe meinen ersten Wochenendspaziergang durch die Stadt gemacht. Und nun darf ich getrost sagen Paris ist nur der Vorort von Zürich in Sachen Sehenswürdigkeiten. An jeder Ecke in der Altstadt sieht man etwas Neues Altes. So gut restaurierte alte Bauten habe ich bisher noch nie gesehen. Gut, Quedlinburg oder Trier sind vergleichbar, aber sie sehen so aus, als ob sie für die Touristen zurecht gemacht wurden. So nicht hier in Zürich. Es ist benutzt und schön zugleich. Wie die Schweizer das machen ist mir ein Rätsel.

Ich hab hier mal ein paar Fotos, aber den tatsächlichen Eindruck können sie in keinster Weise vermitteln. Es gehört so vieles dazu, die Touristen und der Schweizer Dialekt, die Luft – unglaublich, wie klar sie im Vergleich mit Berlin oder Paris ist – die Geräusche, erzeugt von der Straßenbahn (Tram) und den Möven.
Und trotzdem werde ich froh sein wieder zu Hause zu sein, in zwei Wochen.

>Ein Bild entsteht – EBC im Web (Teil 2)

>Wie hier beschrieben, habe ich vor in Einzelschritten eine Web-Applikation unter Anwendung der EBC 2.0 Technik zu entwickeln. In diesem Post soll es um die Findung der Domänen- und Datenobjekte gehen.

Domänen- und Datenobjekte

Eine Applikation ist sinnfrei, wenn sie keinen Zweck erfüllt. Diesen Zweck erfüllt sie zumeist mit den Daten, die innerhalb des internen und externen Systems in Form von Nachrichten oder Entitäten existieren. Domänenobjekte haben eine ganz andere Daseinsberechtigung, nämlich die Applikation verständlicher zu machen. 
Ich kann mir eine Reihe von Objekten im System ausdenken, die ihrem Namen nach nichts mit der Lösung zu tun haben, aber sie könnten dennoch die Umsetzung der Lösung sein. (zu abstrakt schon wieder). Besser ausgedrückt, ich benutze Domänenobjekte, um den Code lesbarer zu gestalten, die Kommunikation mit Kunden zu verbessern und vor allem die Verständlichkeit zu erhöhen.
Zum Finden der Objekte gibt es viele Möglichkeiten. Bisher habe ich das Einzelgespräch mit den Product Ownern gesucht und im Interview herausgefunden, was dem einzelnen für Begriffe am wichtigsten sind. Diesmal möchte ich es ein wenig anders machen, weil ich den Vorteil der Concept Map erleben durfte.

ConceptMap
Version 1
Version 2

Auf den ersten Blick macht die Map einen guten Eindruck. Sollte sich herausstellen, dass ich etwas vergessen habe, dann werde ich natürlich die Map nachträglich anpassen.
Also, was haben wir nun? Ich habe die Idee sowie die geforderten Leistungen vorgestellt und anschließend die Domänen- und Datenobjekte identifiziert. Als nächstes ist es meines Erachtens an der Zeit die Prozesse zu formulieren. Das werde ich im nächsten Post erledigen.
Jan

>Ein Bild entsteht – EBC im Web (Teil 1)

>malen Vor einiger Zeit habe ich damit begonnen das Paradigma EBC in meinen Arbeitsgebrauch auf zu nehmen. Inzwischen sind ein paar Beispiele entstanden und auch viele Beiträge in den Diskussionsgruppen. Aber alles was bis dahin entstanden ist, kann man mehr unter dem Lichte des Proof of Concept sehen.
Um die EBC Technologie weiter voran zu treiben, braucht sie Beispiele. Vor allem welche, die man nachvollziehen kann. Nun das klingt logisch, doch wie so oft liegt der Teufel im Detail.

  • Welche Art von Applikation?
  • Wie realistisch sollte sie umgesetzt werden?
  • Wie geht man mit Veränderung um?
  • Und, wie geht man grundsätzlich an die Umsetzung eines solchen Beispiels heran?

Das alles sind Fragen, die ich mir in den letzten Tagen immer wieder gestellt habe, bis ich zu dem Schluss gekommen bin, das Ganze schrittweise umzusetzen und nicht Alles im Voraus durch zu planen. 
Ich beginne also ganz einfach mit der Ideenfindung, dann erfinde ich sinnvolle Leistungsanforderungen, finde die Domänen- und Datenobjekte, formuliere die Prozesse im System und zu guter Letzt versuche ich das Konzept auch noch in Code umzusetzen.
Das sollte machbar sein.

Was für eine Idee…

In der heutigen Zeit ist es schon fast eine Beleidigung, wenn man keine Web-Applikation als Beispiel anbietet und um mich diesem … zu unterwerfen, habe ich, was für ein Wunder, beschlossen eine Web-Applikation zu entwickeln, die im Bereich datengetriebene Applikation angesiedelt ist. Aus gegebenem Anlass wähle ich ein Projekt aus meinem näheren Umfeld.
Ich möchte ein Bezahlsystem umsetzen, das in einer Web-Applikation eingebettet ist, um erweiterte Inhalte einem Anwender zur Verfügung stellen zu können.

Die Story

“Die Kunden möchten erweiterte Inhalte zum Standard einer Web-Applikation nutzen. Die erweiterten Inhalte sind kostenpflichtig. Um dem Kunden dieses Inhalte zur Verfügung stellen zu können muss er zu seinen schon bekannten Profildaten, Bezahlinformationen hinterlegen und die Art des Bezahlproduktes angeben.”
Das klingt nicht schwer. Zumal der gesamte Bezahlprozess durch einen Dienstleister zur Verfügung gestellt wird. Ihm reichen ein paar Daten zu einem Kunden aus und anschließend übernimmt er die Konto- und Bonitätsprüfung, Kreditkarten Check usw. usf. Ich konzentriere mich also auf wenige Prozesse rund um die Datenvalidierung und die Statusmeldungen vom Bezahldienstleister.
Damit ist die Idee des Beispiels formuliert. Nun “erfinde” ich die Leistungen des Systems und greife abermals in die Kiste der mir schon bekannten Spezifikationen.

Die Story als Konzept

Da ich es mag mit Bildern zu kommunizieren und auch der UML nicht abgeneigt bin, formuliere ich die geforderten Leistungen des Systems in einem Use Case Diagram. Um sicher zu stellen, dass das Diagramm korrekt verstanden wird, möchte ich einmalig den Inhalt des Diagramms zusätzlich in Worten beschreiben.
Leistungsbeschreibung
Leistungen des Systems
Der Anwender ist der Akteur des Systems, er erwartet Leistungen vom System, die seinen Wunsch, kostenpflichtige Inhalte nutzbar zu machen, erfüllen. Die folgenden Leistungen sollen vom System bereitgestellt werden.

  • Der Anwender kann eine Buchung durchführen,
  • Die Buchung besteht aus den Schritten:
    • Produkt auswählen,
    • Rechnungsanschrift eingeben und
    • Zahlungsart auswählen,
  • Eine Buchung wird mit einer Email bestätigt und
  • Die Daten der Zahlungsarten werden während des Buchungsvorganges verifiziert.

Damit ist das Grundgerüst für die Applikation in Form einer Leistungsbeschreibung aufgestellt worden. Der nächste Schritt wird sein, die Domäne und die Dazugehörigen Daten zu beschreiben.
Soweit so gut, damit der Post nicht zu lang wird, möchte ich die Beschreibung der Domäne und der Daten in einem nächsten Post veröffentlichen.

Jan