Wissenstransfer durch Review?

31 Oktober 2014

Es gibt ja diverse Ideen, Wissen über ein laufendes System und dessen Kontext von einem Wissenden zu einem Unwissenden zu übertragen. Dokumentationen zu schreiben ist sicherlich nicht die Lieblingsaufgabe eines Softwareentwicklers; aber es gehört dazu. Diese als Softwareentwickler auch zu lesen, ist meist ebenfalls wenig spannend, wenn man ein System kennen lernen möchte; insbesondere wenn diese dann auch noch veraltet ist und die Wahrheit sowieso im Code steht. Eine Dokumentation zu lesen ist also eher wenig geeignet. Es geht auch nicht in kurzer Zeit, sondern ist ein Prozess. Hier möchte ich einmal veranschaulichen, wie man Schritt für Schritt jemanden ein System näher bringen kann. Dabei soll darauf geachtet werden, dass beide Seiten nicht frustriert werden und für beide (gern auch für Dritte) ein Mehrwert entsteht.
Der fachliche Kontext eines Systems ist in der Regel schnell erklärt durch Fragen wie:
– Warum ist das System da?
– Was sind die Hauptfunktionen des Systems?

Wie etwas umgesetzt ist und warum interessiert an dieser Stelle nicht; das ist zuviel Detail für jemanden, der das System kennenlernen soll. Das langweilt in der Regel und die Aufnahmefähigkeit des Menschen ist eben auch nur begrenzt. Ein Wissender kann hier schnell über das Ziel hinausschießen. Natürlich sollen aber auch die Fragen der Unwissenden berücksichtigt und beantwortet werden.

Der nächste Schritt ist dann, den Unwissenden die Tücken des Systems entdecken zu lassen – selbstständig; ab ins kalte Wasser! Angenommen es gibt rund um das System wiederkehrende Aufgaben zu erledigen. Dann lässt man den Unwissenden diese erledigen. Er wird einen Teil vielleicht schon allein durch die beantworteten Fragen alleine lösen können. Für den anderen Teil wird er auf den Wissenden zugehen. So entdeckt der Unwissende nach und nach das System und kann vielleicht auch die ersten Zusammenhänge erkennen. Das Ganze immer zusammen mit dem Wissenden. Es ist also wichtig, dass sch der Unwissende traut, bei ihm im Zweifelsfall nachzufragen. Dazu sollte man abhängig vom System einen Zeitraum absprechen, der die Tücken auch erkennen lässt. Bei einem System, das jeden Tag läuft könnte das eine Woche sein.
Sollten die Tücken gar nicht oder nicht vollständig dokumentiert sein, wird der Unwissende in der Regel von sich aus dies nachholen. Dies dann für alle zugreifbar zu machen, ist anschließend nur noch ein kleiner Schritt.

Im nächsten Schritt geht es dann in den Code. Pair-Programming macht in einem solchen Fall keinen Sinn, da der Wissensstand einfach viel zu unterschiedlich ist. Der Wissende wird für den Unwissenden zu schnell zwischen den Klassen hin- und herspringen und der Unwissende fühlt sich unsicher, weil der Wissende ihm zeigt, wie es gehen muss; auf beiden Seiten Frust!
Der Unwissende soll also sein Tempo selbst bestimmen und seine eigenen Ideen entwickeln können. Dazu sollte er eine Aufgabe bekommen, die in sich abgeschlossen ist und in wenigen Stunden erledigt werden kann. Der Wissende sollte dann bereit sein, eine Einstiegshilfe zu geben; also Klassen nennen, die mit der Aufgabe zu tun haben. Anschließend kann der Unwissende den Kontext der Klassen analysieren und die Aufgabe lösen.
Anschließend legt der Unwissende die Lösung dem Wissenden zum Review vor. Dafür gibt es sehr gute Tools wie Atlassian Crucible. Am Anfang wird es unter Umständen viele Anmerkungen geben. Aber
der Unwissende wird immer mehr zum Wissenden, je mehr Aufgaben er löst. Wenn es viele Aufgaben in kurzer Zeit gibt, ist es sehr schnell soweit, dass der zunächst Unwissende mit dem Wissenden über Lösungen diskutieren kann. Dann ist auch die Zeit für Pair-Programming gekommen.

Speziell die Reviews sind eine sehr gute Unterstützung für Feedback und bieten die Möglichkeit für Diskussionen fokussiert auf den Code; nur von Änderungen betroffene Klassen werden betrachtet.
Die beschriebenen Schritte werden nicht unter allen Umständen funktionieren. Aber wenn beide Seiten motiviert sind, das Wissen zu teilen und auch Neues aufzunehmen (beides gilt für beide Seiten), profitieren beide Seiten und am Ende natürlich auch der Arbeitgeber oder Kunde.

SEPA-Dateien durchsuchbar machen

27 Oktober 2014

Am 09.10.2014 wurde mein insgesamt 4. Pressebericht von meinem Arbeitgeber veröffentlicht: Big Data durch SEPA: Mehr Zahlungen, mehr Transaktionen, mehr Kosten.
Dort habe ich beschrieben, wie man mit einer nicht relationalen Datenbank Transaktionen abspeichern könnte. In meinem aktuellen Projekt setzen wir dafür Elasticsearch ein.
Dies war allerdings nicht unsere erste Lösung. Zunächst haben wir Apache Lucene verwendet. Dies wird auch in Elasticsearch verwendet. Allerdings kapselt Elasticsearch einiges an Komplexität weg, sodass mit Einstellungen im Auslieferungszustand sehr schnell Informationen durchsuchbar gemacht werden können. Elasticsearch hatte zu Beginn allerdings einen Nachteil: Man kann die Informationen nicht auf einen Schlag sichtbar machen. Da man Transaktionen getrennt von einander speichern möchte, kann man bei z.B. 10.000 Transaktionen innerhalb einer Datei nicht erst alle Transaktionen für eine Suche sichtbar machen, wenn die 10.000. Transaktion indiziert wurde. Die suchende Applikation muss mit diesem Umstand umgehen können. Deshalb haben wir zunächst Apache Lucene direkt verwendet, da man dort einen commit-Mechanismus hat, der das Beschriebene bietet. Allerdings haben wir dazu für die gesamte Datenmenge einen einzelnen Index verwendet. Das hat die Anwendung so sehr verlangsamt, dass wir Gefahr liefen, einen Tag mit etwa 10 Millionen Transaktionen nicht innerhalb von 24 Stunden verarbeiten zu können. Da wir bisher maximal die Menge der letzten 8 Wochen vorhalten müssen, machte es für uns Sinn, die Transaktionen in mehreren Indizes zu unterteilen. Da sich außerdem die Indizes der vergangenen Tage nicht verändern, sondern nur der aktuelle Tag, ist ein Tag die beste Größe für einen Index aus unserer Sicht.
Dafür bringt Elasticsearch einiges mit. Denn eigentlich ist es für den Aufbau eines Clusters, also Verteilung auf mehrere Server-Instanzen, konzipiert, um die Last zu verteilen. Mit Hilfe von Index-Aliasen lassen sich dann mehrere Indizes durch nur einen Namen ansprechen. Jede Abfrage wird ja zu einem bestimmten Zeitpunkt ausgeführt. Da wird der Datumsteil entnommen und der entsprechende Alias draus erzeugt. Anschließend wird abgefragt, ob es den Index gibt. Ist dies nicht der Fall, wird für den vorherigen Tag das gleiche Vorgehen ausgeführt, solange bis ein Index gefunden wird oder eine andere Abbruchbedingung greift. Damit nicht bei jeder Abfrage überprüft werden muss, ob es den Index gibt, sollte man natürlich den aktuellen Alias cachen, wenn man ihn bereits geprüft hat.
Der Entwickler bekommt also einiges an die Hand, um ein solches Konstrukt aufzubauen. Nur den Commit-Mechanismus verliert man mit Elasticsearch. Wie man diesen soweit wie möglich nachbilden kann, beschreibt Patrick Peschlow unter Transactions in Elasticsearch.
Zu den Informationen, nach denen wir suchen wollen, werden die notwendigen Informationen für die Prozesse abgespeichert. Das ist unter anderem auch der Dateiname und die Positionen der maximal drei Ebenen einer Datei (Datei-, Gruppe- und Transaktionsebene) innerhalb der Datei. Mit Hilfe dieser Informationen können zu jeder in der Recherche vorliegenden Transaktion die drei Ebenen einer Transaktion als XML-Zeichenkette ermittelt werden. Mit Hilfe dieser Zeichenkette von Original-Transaktionen (pacs.003 (Lastschrift) und pacs.008 (Gutschrift)) lassen sich dann automatisch R-Transaktionen mit Hilfe eines entsprechenden Konverters erzeugen. Dies lässt sich z.B. nutzen, um Validation-Files von anderen Clearing-Häusern automatisch zu verarbeiten. Auch eine Maske mit den bereits vorerfassten Daten einer Original-Transaktion lässt sich so umsetzen. Es sind viele Möglichkeiten denkbar.
Mit dem beschriebenen Konstrukt ist es möglich, über eine Milliarde Dokumente schnell zu durchsuchen; ohne große Wartezeit selbst an Tagen mit über 40 Mio. Transaktionen. Die größte Hürde stellt bisher noch die Bereitstellung der Daten dar: Innerhalb kürzester Zeit sollen mehrere hundert Megabyte-große Dateien durchsuchbar sein. Dies lässt sich nur durch parallele Verarbeitung lösen. Bisher ist diese leider nicht effizient genug, da mehrere große Dateien auch mal einen Prozess verstopfen können, während alle anderen Prozesse auf Dateien warten. Dies ist aber unbestritten der Art der Bereitstellung geschuldet: Die Dateien kommen in einem Verzeichnis an und werden dann von einem Prozess auf verschiedene Unterverzeichnisse verteilt. Für jedes Unterverzeichnis gibt es dann einen eigenen Prozess, der die Dateien verarbeitet. Leider ist die Verteilung nicht “schlau” genug, um zu erkennen, ob in dem Unterverzeichnis nicht bereits mehrere große Dateien liegen. Wenn diese Parallelisierung verbessert werden könnte, wäre die Echtzeit-Suche nicht mehr weit entfernt, um die automatischen Massenzahlungsverkehrsprozesse noch weiter zu verbessern.

Komplexität und Story Points

22 September 2013

In meinem aktuellen Projekt sollen Story Points eingeführt werden, um von den „idealen Tagen“ (8 Stunden Vollzeit für das Projekt) wegzukommen.

Die theoretische Einführung war dabei komplizierter als die tatsächliche Anwendung. Denn in der Theorie sollen Story Points ein Maß für die Komplexität einer Aufgabe sein.
Für mich war die Komplexität einer Aufgabe allerdings nicht so einfach zu bestimmen. Nach meinem bisherigen Verständnis hat Komplexität nichts mit der Anzahl an notwendigen Wiederholungen bei der Lösung einer Aufgabe zu tun. Angenommen die Aufgabe besteht darin, Kies von A nach B zu bringen, dann könnte die Lösung darin liegen, eine Schaufel zu nehmen, Kies drauf zu packen und von A nach B zu bringen. Wenn zur Aufgabe dann noch eine weitere Informationen dazu kommt, wird die Aufgabe durch die Anzahl der Informationen zwar komplexer, aber deren Umsetzung muss dadurch nicht komplexer werden.
Im genannten Kies-Beispiel könnte die zusätzliche Information sein, dass eine Tonne Kies von A nach B zu bringen. Dann könnte die Lösung darin liegen, den Kies mit einer Schaufel zu transportieren. Die Lösung der Aufgabe ist dann ebenso komplex wie die Lösung ohne zusätzliche Information.
Da Sprints aber nicht unendlich lange dauern, könnte die Lösung mit der Schaufel allerdings nicht zielführend sein. Dadurch kommt aber eine weitere Information zur Aufgabe hinzu. Dies führt zu einer weiteren Erhöhung der Komplexität der Aufgabe. Es muss also eine andere Lösung gefunden werden. Die Lösung könnte ein Radlader sein, dessen Schaufel mit Kies an A befüllt und an B entleert wird. Die Lösung der Aufgabe wird dadurch komplexer, da man jemanden haben muss, der das Gerät fahren kann. Wenn man sojemanden im Team nicht hat, ist die Lösung der Aufgabe für das Team sehr komplex, da die Lösung für das Team unter Umständen etwas noch nie Dagewesenes darstellt. Eine Alternative zur genannten Lösung kann natürlich sein, dass man weiterhin die Schaufel nimmt und die Aufgabe auf mehere Sprints verteilt.

Aber warum ist es überhaupt relevant, was man mit Story Points misst? Eigentlich geht es bei Story Points doch nur um eine abstrakte Größe, die man in Relation setzen kann. Irgendwie möchte ich bestimmen, ob Aufgabe B komplexer ist als Aufgabe A. Nach meinem Verständnis ist es aber irrelevant, wie komplex eine Aufgabe ist. Es geht allein um den Schwierigkeitsgrad der Lösung.
Bei der Sprintplanung muss das Team sich also grob auf eine Lösung der Aufgabe einigen und diese in Relation zu den Lösungen anderer Aufgaben setzen.

Story Points sagen also nichts über die Komplexität einer Aufgabe aus, sondern sie beziehen sich auf die Lösung der Aufgabe. Die Relation der Lösungen zueinander ist von Team zu Team unterschiedlich, da jedes Team unterschiedliche Erfahrung hat, um die Lösungen in Relation zu setzen.

Das Konzept hinter Story Points ist aus meiner Sicht das Entscheidende: Der Aufwand zu einer Aufgabe wird abgeleitet und nicht geschätzt. Wie groß, schwer oder komplex die Lösung der Aufgabe ist, liegt am Verständnis des Teams. Dies muss sich nur bei den Referenz-Lösungen einig sein.

Pressebericht über SEPA

19 Juli 2013

Ich habe es mal wieder getan…

Heute wurde mein dritter Pressebericht veröffentlicht! Unter SEPA: Bei IBAN-Only gibt es nur Verlierer! oder in der Pressebox ist er zu finden.

SEPA und das Wirrwarr mit Dateiformaten

06 Oktober 2012

Vor ein paar Wochen wurde mein Pressebericht SEPA – nur eine Absichtserklärung? veröffentlicht. Darin kritisiere ich die fehlende Standardisierung der Zusammenfassung von verschiedenen Nachrichtenarten in einer Datei.

Ab spätestens 2014 wird die Anzahl der SEPA-Transaktionen deutlich zunehmen. Damit nimmt auch die Größe von XML-Dateien zu. Bereits heute haben die Dateien eine Größe von mehreren zig Megabyte. Schon mit diesen kleinen Dateigrößen kann es problematisch sein, die Dateien mit einem Editor zu öffnen. Zwar sollten die Dateien in der Regel automatisch verarbeitet werden und keine Notwendigkeit bestehen, sie mit einem Editor zu öffnen. Allerdings zeigt die Praxis, dass dies vorkommt. So wird z.B. eine Datei von einem Clearing-Institut abgewiesen und damit nicht verarbeitet. Das Clearing-Institut schickt dann eine Datei, wo der Grund für die Abweisung der Datei enthalten ist. Es kann auf Datei-, Gruppen- und Transaktionsebene jeweils einen Grund geben. Wenn z.B. nur eine Transaktion abgewiesen wird, so wird auf Dateiebene angegeben, dass nur ein Teil der Datei akzeptiert wurde. Für jeden Bulk, der vollständig akzeptiert wurde, wird der entsprechende Code angegeben. Nur der Bulk mit der fehlerhaften Transaktion bekommt einen anderen Code und zusätzlich wird die Transaktion angegeben, die fehlerhaft ist. Für jede der Ebenen gibt es eine Auswahl von (Fehler-)Codes.
In trivialen Fällen kann eine R-Transaktion erstellt werden und die Original-Transaktion an den Absender zurückgegeben werden. In der Regel sollte eine solche Transaktion natürlich gar nicht erst an das Clearing-Institut übergeben werden. Es gibt aber natürlich Fehler, die genau dazu führen.
In komplexeren Fällen muss aber manuell eingegriffen werden. So wird z.B. ein ganzes Bulk abgewiesen weil alle darin enthaltenen Tranaktionen, die darin enthalten sind, abgewiesen wurden. Der entsprechende Fehlercode sagt genau dies aus. Wenn in dem Bulk nur eine Transaktion enthalten war, hilft dieser Code natürlich nicht bei der Behebung des Problems. Also schaut man sich die Original-Transaktion an. Wenn die Datei, die die Transaktion enthält, aber so groß ist, dass sie mit einem Editor nicht mehr geöffnet werden kann, steht man vor einem Problem.

Die Systeme, die heute für die Verarbeitung von SEPA-Dateien entwickelt werden, sollen mit mehreren Gigabyte großen Dateien umgehen können. Damit nicht nur Maschinen deren Inhalt verstehen, sondern auch Menschen vor dem Bildschirm, wurde das XML-Format gewählt. Wenn aber die Dateien wegen ihrer Größe gar nicht erst geöffnet werden können, macht das aus meiner Sicht alles keinen Sinn mehr. Deshalb verstehe ich nicht, warum Bulks in nur einer Datei zusammengefasst werden.
Letztendlich werden die Bulks sowieso getrennt voneinander verarbeitet. Wenn verschiedene Nachrichtenarten ausgetauscht werden, werden die Dateien also wieder zerpflückt, die vorher für den Austausch zusammengefügt wurden.
Warum werden mehrere ISO20022-konforme Dateien nicht zu einer Datei zusammengefasst, so wie man es von ZIP-Archiven kennt? Eine Datei mit einem standardisiertem Namen (z.B. „header.xml“) könnte als Container für Informationen über das Archiv genutzt werden. Das hätte viele Vorteile:

ISO20022 dient als vernünftige Vorlage für das SEPA-Dateiformat. Was die Clearing-Institute bisher daraus gemacht haben, ist leider in vielen Belangen nicht optimal.


Alte Einträge sind verfügbar im Archiv.