Dienstag, 8. Dezember 2015

Teaser: Der dunkle Bruder des Feedback

Feedback ist nötig. Umso mehr, je unsicherer ist, was eigentlich geleistet werden soll und ob man das schon geleistet hat. Deshalb sind in der Agilität zwei Feedbackschleifen explizit institutionalisiert: Durch automatisierte Tests bekommen Entwickler innerhalb von Sekunden oder Minuten Feedback, ob Veränderungen zu Regressionen geführt haben. Durch Reviews des Implementierten mit Stakeholdern am Ende kurzer Iterationen bekommen Entwickler Feedback innerhalb von Tagen oder wenigen Wochen, ob sie ihr Werkstück näher an die Zielvorstellung jener heranentwickelt haben.

Mit der Agilität ist das Feedback aus dem Schatten von Gevatter Plan getreten. Das ist eine zentrale Leistung der Agilität.

Doch irgendetwas stimmt nicht. Es herrscht jetzt nicht einfach Friede. Die Entwicklung schreitet nicht einfach zügig voran. Ganz merkwürdig zagt und stolpert sie immer noch – trotz des klaren, sauberen Anführers Feedback.

Das liegt an einer Kraft, die bisher unbenannt ist. Sie beeinflusst den Fortschritt stark, doch niemand benennt sie so recht. Alle kennen sie, aber man räumt ihr keinen gleichwertig offiziellen Platz neben dem Feedback ein. Ich will sie deshalb den dunklen Bruder des Feedback nennen.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Freitag, 4. Dezember 2015

Teaser: Microservices verbinden in Datenflüssen

Mir hat der Blogartikel von Tobias Flohre gut gefallen, in dem er die Kommunikation zwischen Microservices mit asynchronen Events beschreibt. Er tut das als Gegenentwurf zu einer Darstellung mit BPMN und einer Implementation auf der Basis einer Workflow-Engine.

Entkoppeln mit Events

Gut gefallen hat mir der Artikel, weil Tobias damit eine Lanze für das Principle of mutual Oblivion (PoMO) bricht. Es besagt, dass Funktionseinheiten in Software nicht funktional abhängig von einander sein sollen. Logik in der einen sollte Logik in der anderen nicht kennen, nicht nutzen. Jede Funktionseinheit sollte vielmehr quasi selbstvergessen “nur ihr Ding machen” und sich nicht um die Umwelt scheren. So tut das in einem Organismus jede Zelle; warum also nicht auch jede Funktionseinheit in einer Software? (Das ist aus meiner Sicht sogar, was Alan Kay ursprünglich unter Objektorientierung verstanden hat. Hier dazu eine Artikelserie von mir: OOP as if you meant it.)

Ich schreibe hier bewusst “Funktionseinheit”, weil ich auf konzeptioneller Ebene spreche. Eine Funktionseinheit kann im Code eine Funktion oder eine Klasse… oder eben auch ein Microservice sein. Eben ein Modul als Träger von Verhalten herstellender Logik.

Eine PoMO-konforme Funktionseinheit bekommt von irgendwoher “etwas”, arbeitet daraufhin und liefert anschließend “etwas anderes” ab. Woher “etwas” kommt, wohin “etwas anderes” geht, das ist der Funktionseinheit einerlei. Das mag seltsam klingen – doch Sie sind damit ganz vertraut. Jede Funktion T f<S,T>(S s) arbeitet so.

Hier ein Beispiel für eine solche Funktionseinheit aus Tobias’ Artikel:

[Lesen Sie den ganzen Artikel in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Donnerstag, 3. Dezember 2015

Teaser: Ziele erreichen mit tugendhafter Emergenz

Manche Ziele scheinen mir so schwer erreichbar, dass ich denke, man kann sie gar nicht direkt erreichen.

Wie sieht es mit einem erfolgreichen Unternehmen aus? Oder was tun, um Software stets wandlungsfähig zu halten? Kann man auf diese Ziele Maßnahme für Maßnahme zugehen?

Probleme zentraler Steuerung

Es wird schwer, auf ein Ziel zuzusteuern, wenn man die dafür relevanten Teile und Aktivitäten nicht mehr überblickt. Solange man sie überblickt, kann man versuchen, sie direkt anzusteuern. Jenseits des Überblicks jedoch… das stellt sich schnell ein Gefühl des Kontrollverlustes ein – umso mehr, je stärker man glaubt, doch eigentlich zu wissen, was zu tun nötig ist.

Unabhängig vom Überblick kann es aber auch an Zeit mangeln. Selbst wenn eine zentrale Instanz wüsste, wie Teile zu steuern wären, kann es schlicht zu lange dauern, sie zu informieren und auf Antwort zu warten, um angemessen schnell zu reagieren.

Und schließlich noch die Inkompetenz. Egal wie groß die Zahl der Teile und wie lang die Kommunikationswege: wenn die Komplexität wächst, werden in Bezug zu ihr zentrale Entscheider zunehmend inkompetent. Sie können einfach nicht mehr wissen, was zu tun ist, um gewünschte Zustände durch konkrete Steuerungsmaßnahmen zu erreichen. Das ist nur möglich, solange die Situationen kompliziert sind.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Dienstag, 1. Dezember 2015

Teaser: Bereiche der Schätzbarkeit

In den letzten beiden Tagen habe ich mal wieder zusammen mit Andrea Kaden einen Zeitmanagement-Workshop für Softwareentwickler gegeben. Natürlich kamen wir dabei auch auf das Thema Schätzung. Das treibt Entwickler immer wieder und immer noch sehr um. Sie empfinden schlicht großen Stress, wenn es vorhersagbar nicht klappt, Schätzungen einzuhalten. Sie fühlen sich unwohl, zur Unehrlichkeit gezwungen zu werden.

Das verstehe ich sehr gut. Deshalb bemühe ich mich, Hilfestellung bei diesem Thema zu geben. Ich versuche zu erklären, warum es mit dem Schätzen schwer bis unmöglich ist. Ich versuche, einen alternativen Weg aufzuzeigen, auch ohne Schätzungen verlässlich wertvolle Software herzustellen. Ich verweise auf andere, die auch versuchen, Entspannung zu vermitteln.

Deshalb heute auch dieser Blogartikel. Ein weiterer Versuch, Softwareschätzungen besser verständlich zu machen. Und zwar ausgehend von einer Analogie.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Freitag, 27. November 2015

Teaser: Tests als evolutionäre Kraft

Warum sollte Software eigentlich eine bestimmte Struktur haben? Weil sie mit dieser Struktur den Kräften, die an ihr wirken, am besten standhalten kann.

Dass Software gewünschte Funktionalität zeigt, hat nichts mit ihrer Struktur zu tun. Dass Software gewünsche Effizienzen zeigt (z.B. Performance, Sicherheit), hat in vielen Fällen auch nichts mit ihrer Struktur zu tun. Für Funktionalität wie Effizienzen ist lediglich Logik verantwortlich – und die braucht keine Struktur, um ihren Effekt zu entfalten.

Das ist leicht zu verstehen, wenn Sie daran denken, dass im finalen Maschinencode all Ihre schönen Strukturen ja nicht mehr zu finden sind und die Software trotzdem das gewünschte Verhalten zeigt.

Was verstehe ich unter Struktur? Elemente, die in Beziehung stehen. Also eine gewisse Anordnung von Dingen. Diese “Dinge” in der Software sind zunächst einmal Module, d.h. Funktionen, Klassen, Bibliotheken usw. Und die Beziehungen zwischen ihnen sind vor allem Nutzungsbeziehungen: ein Modul kennt ein anderes, um dort eine Dienstleistung zu nutzen.
(Datenstrukturen lasse ich hier ausdrücklich aus. Die arrangieren ja keine Logik, sondern eben Daten.)

Und was sind die Kräfte, die auf die Softwarestruktur wirken? Veränderungen. Softwarestruktur soll Code wandelbar machen.

Wandelbar ist Code, wenn er leicht verständlich ist, wenn sich Veränderungen zur Herstellung neuer Funktionalität oder Effizienz leicht anbringen lassen und wenn man leicht feststellen kann, ob das Neue schon korrekt implementiert ist wie auch das Alte immer noch korrekt arbeitet. Testbarkeit ist mithin ein Kriterium für Wandelbarkeit. Tests sind ein Teil der Kraft, die auf Softwarestrukturen einwirken.

In Bezug auf Tests habe ich mich nun gefragt, wie sich Strukturen dadurch verändern? Wie setzt Software Tests möglichst wenig Widerstand entgegen?
Mir scheint es da eine natürliche Entwicklung zu geben, quasi eine Evolution.

[Mehr lesen Sie in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Samstag, 10. Oktober 2015

Gelebte inkrementelle Dekomposition

Neulich war große Freude. Ein Produktentwicklungsteam eines Kunden zeigte mir, wie es meinen Vorschlag eines anderen Umgangs mit Anforderungen umsetzt - und dadurch flüssiger arbeitet.

Inkrementelle Dekomposition

Mein Vorschlag war und ist, Anforderungen des Kunden bzw. die User Stories eines Product Owners nach einem Schema “zu zermahlen”, um für die weitere Entwicklung sehr präzise Ausgangspunkte zu bekommen.

Ausführlicher habe ich dieses Schema in einem früheren Artikel beschrieben. Deshalb skizziere ich es hier nur noch und stelle es in einen Prozesszusammenhang.

Für mich sieht ein Teil des Softwareproduktionsprozesses so aus:

image

Ein Strom von unstrukturierten Anforderungen wird von einem Product Owner im Rahmen eines so genannten Story Development durchgekaut und in User Stories transformiert. Die sind klein, konkret, wertorientiert, priorisiert.

Allerdings sind User Stories rein aus der Sicht von Kunde/Anwender formuliert. Die Programmierung kann sie nicht einfach implementieren. Vielmehr muss darauf eine Vorverarbeitung stattfinden.

Entwickler (und Tester) sitzen dafür zunächst mit dem Product Owner zusammen und analysieren die User Stories. Bisher hat ja nur der Product Owner verstanden, was zu tun ist. Dieses Wissen muss in die Köpfe der Programmierer übertragen werden. Das bedeutet, die Welt des Problems muss an die Welt der Lösung angeschlossen werden. Es müssen Bezüge hergestellt werden, ein Mapping stattfinden.

Mit meinem Ansatz plädiere ich dafür, die User Stories “in einen Problemtrichter zu stopfen”, aus dem unten einzelne Funktionen mit zugehörigen Akzeptanzkriterien heraustropfen.

User Stories stellen die Anforderungen in Form von Inkrementen vor, d.h. für den Kunden wertvolle Zuwächse an Funktionalität oder Effizienz. Slices sind Inkremente mit konkretem Bezug zur Welt der Codierung, d.h. der Lösung.

Die Problemanalyse transformiert einen Strom von User Stories also in einen Strom von Slices unterschiedlicher Dicke. Hier die Liste der wichtigsten Slices mit den ihnen entsprechenden Programmierartefakten (Module):

  • Anwendung = Bibliothek
  • Dialog = Klasse
  • Interaktion = Funktion
  • Feature = Funktion

Jede User Story entspricht dann in der Hierarchie der Slices einem oder mehreren Pfaden der Form Anwendung/Dialog/Interaktion/Feature. Das ist für die weitere Programmierung sehr, sehr viel konkreter, als eine User Story. Die Programmierung fühlt sich auf diese Weise weniger allein gelassen mit Verständnis und Übersetzung von Anforderungen. Ja, die Programmierung bekommt durch die gemeinsame Problemanalyse mit dem Product Owner sogar schon konkrete Hinweise auf eine minimale Modularisierung des Codes. Und die spiegelt dann auch noch das agile Vorgehen wider.

Während üblicherweise User Stories nach der Implementation nicht mehr im Code zu erkennen sind, bleiben bei diesem Vorgehen Inkremente als Artefakte im Code erhalten. Das ist von unschätzbarem Wert für die Nachvollziehbarkeit und Verständlichkeit von Code.

Der ursprüngliche Strom von Anforderungen wird also in zwei Schritten zerlegt in Inkremente (inkrementelle Dekomposition):

  1. Story Development -> User Stories
  2. Problemanalyse -> Slices

Beide zusammen dienen der Qualitätssicherung des Input in die weitere Programmierung. Das ist wichtig, da einer der häufigsten Engpässe bei der Softwareproduktion die Implementation oder die anschließende QA ist. Hohe Inputqualität für den Engpass ist Voraussetzung für hohe Qualität seines Output. Und die ist wichtig, damit der Engpass später nicht mit Nachbesserungen belastet wird.

Soweit die Theorie. Jetzt die Praxis.

Im realen Projekt

Als Trainer in Sachen flüssige Softwareproduktion und Clean Code Development stelle ich diese Vorgehensweise vielen, vielen Entwicklern vor. Wir üben sie dann tapfer in Workshops. Doch die Übertragung solcher “Theorie” in den Arbeitsalltag fällt den Teilnehmern immer wieder sehr schwer. Über die Gründe kann man diskutieren und lamentieren - aber nicht heute. Heute möchte ich zur Abwechslung zeigen, wie der Transfer eben auch klappen kann.

Das Team bei meinem Kunden besteht im Wesentlichen aus 2 Entwicklern, 3 Testern und 1 Product Owner. Beide Entwickler hatten an 2 Schulungstagen der Clean Code Developer School teilgenommen, an denen wir uns auf den Umgang mit Anforderungen konzentriert hatten. Dann am Ende des dritten Schulungstages luden sie mich ein, sich ihre Umsetzung des Lernstoffes in ihrem team room einmal anzusehen.

An der Wand sah ich dort diesen Notizenbaum:

image

Die Anwendung, an der das Team arbeitet, steht außer Frage. Die muss nicht explizit modelliert werden.

Der Dialog, auf den sich die (derzeit) zu realisierenden User Stories beziehen, steht ebenfalls außer Frage. Die ganze Wand konzentriert sich auf diesen Dialogentwurf:

image

Aus diesem Grund ist der Dialog auch nicht an der Wand zu sehen. Das finde ich verständlich, aber meine Empfehlung ist, ihn dennoch dort ebenfalls zu visualisieren. Dadurch wird jedes Denken über Slices konkreter. Bei Diskussionen kann man leichter Bezug nehmen, um über Interaktionen und Features zu sprechen. Niemand muss im Zweifelsfall in irgendwelchen Dokumenten nach dem aktuellen Stand des Dialog-Layouts suchen.

Aber auch ohne Dialog finde ich die Darstellung an der Wand klasse. Dort sind nämlich die von mir vorgeschlagenen Slices systematisch als Baum zu sehen:

  • Quer über die Wand stehen grüne Karten für Interaktionen des Dialogs. Jede lässt sich einem Button oder dem Klick auf eine Liste usw. zuordnen.
  • Senkrecht stehen orange und gelbe für Features der jeweiligen Interaktion. Die Darstellung der Feature-Hierarchie ist an der Wand leider begrenzt. Mit Farben wurden zwei Ebenen unterschieden und es gibt eine gewisse physische Unterordnung. Letztlich kommt hier der Umgang mit Kärtchen aber an seine Grenzen. Doch das Team ist kreativ mit seinen Mitteln umgegangen. Super!

An diese Wand kann ich herantreten, eine beliebige Karten auswählen und bin sicher, dafür eine Entsprechung im Code zu finden. Da es sich um Interaktionen und Features handelt, gibt es für jede 1 Funktion im Code.

Das ist die Sicht der Entwickler. Gleichzeitig stellt jede Karte aber auch noch Wert für den Product Owner dar! Alle Karten repräsentieren Inkremente. Zu allen Karten kann der Product Owner Feedback geben, ob das gewünschte Verhalten schon nach seinem Geschmack umgesetzt wurde.

(Zu dieser Regel gibt es nur eine Ausnahme: Die zweite grüne Karte von Links steht nicht für eine Interaktion sondern für die Datenstruktur des Dialogs, d.h. für die Steuerelemente mit den zugehörigen Datentypen und einige Validationsregeln. Dass dies visualisiert wird, ist natürlich eine gute Sache. Doch ich empfehle eine deutliche Unterscheidung von den Slices, z.B. durch räumliche Trennung oder andere Farben.)

Diese Systematik zu sehen, hat mich schon begeistert. Doch das Team zeigte mir noch mehr. Es setzt nämlich auch meine Empfehlung um, einzelne Features dem Product Owner über einen Prüfstand zum Feedback vorzulegen.

Hier der Prüfstand für den Cluster von Features, den ich an der Wand hervorgehoben habe:

image

Der Product Owner (oder auch ein Tester) kann mit dem Prüfstand wie mit einer speziellen Messsonde gezielt einen kleinen Teil des Gesamtverhaltens prüfen, ohne die ganze Anwendung oder auch nur den ganzen Dialog zu bemühen.

Das macht erstens das Feedback einfacher. Zweitens wird der Product Owner damit frei, sich Features in quasi jeder beliebigen Reihenfolge zu wünschen. Und drittens können Features, Interaktionen, Dialoge nun viel einfacher parallel entwickelt werden.

Voraussetzung für den Prüfstand ist, dass Inkrement-Wünschen des Product Owners sehr konkrete Artefakte der Programmierung zugeordnet sind. Genau das leistet die inkrementelle Dekomposition mit der Herstellung von Slices jedoch.

Das Fazit von Entwicklern wie Testern sowie Product Owner bisher: die Softwareproduktion ist viel flüssiger geworden.

Darüber freue ich mich sehr! Und ich bin überrascht. Denn so eine pragmatische und zügige Umsetzung des in der CCD School vorgestellten Ansatzes hatte ich bisher noch nicht gesehen. Hier zeigt ein Team, was möglich ist, wenn man echt etwas verändern will. Die Initiative zweier motivierter Entwickler reichte aus, die anderen Teammitglieder waren offen für eine Veränderung und die Führungsebene darüber hat den Freiraum zu solcher Selbstorganisation gegeben.

Drei notwendige Faktoren sind bei diesem Kunden also glücklich zusammengekommen. Super!

Mehr Fluss, mehr Produktivität sind möglich mit systematischerer Softwareproduktion. Das so deutlich zu sehen, spornt mich an, nicht nachzulassen bei der Vermittlung von und Suche nach besseren Methoden.

Mittwoch, 9. September 2015

Eine Chance zur Integrationshilfe

Eigentlich ist für mich als Hamburger die Flüchtlingswelle, die nach Deutschland fließt, eine recht abstrakte Größe. Am Straßenbild hat sich für mich bisher nichts verändert. Menschenbunt ist Hamburg schon lange. Nur die Medien hatten mir bisher davon berichtet, was da so zukunftsverändernd gerade massiv passiert.

Jedenfalls bis neulich. Denn da habe ich Nour Saeed aus Syrien kennengelernt.

image

Aber der Reihe nach: Eigentlich hatte ich ein kleines Programmierprojekt, das ich outsourcen wollte. Zuerst wollte ich den Entwickler in Indien wieder engagieren, mit dem ich schon einmal zusammengearbeitet hatte. Doch dann überlegte ich, dass dies vielleicht eine Chance sei, einem Flüchtling zu helfen. Unter denen gibt es doch bestimmt auch Softwareentwickler. Nur wie das herausfinden?

Da fügte es sich, dass ich einen Hinweis auf die Plattform workeer.de bei facebook sah. Manchmal ist facebook doch tatsächlich nützlich ;-) workeer.de bezeichnet sich als “Die erste Jobbörse für Geflüchtete und Arbeitgeber, die ihnen Chancen eröffnen wollen.”

Also habe ich die Liste der Jobsuchenden durchgeblättert und fand sogar einen Softwareentwickler mit C#-Kenntnissen darin: Nour Saeed. Bingo, Glückstreffer!

Nach Anmeldung bei workeer.de konnte ich mit ihm Kontakt aufnehmen. Er spricht derzeit noch kein Deutsch, aber mit Englisch ging es auch. Also begannen wir über die Konditionen zu verhandeln, wie er für mich tätig werden könnte.

Nour ist als Flüchtling anerkannt und darf in Deutschland arbeiten. Das Jobcenter stellt ihm eine Wohnung zur Verfügung und darüber hinaus noch 400€, von denen er einen Teil für die Wohnung abgibt, Elektrizität und den Internetzugang bezahlt - und dann von ca. 300€ seinen Lebensunterhalt bestreitet. Allerdings weiß Nour nicht, wie unser Arbeitssystem funktioniert. Wo ist der Unterschied zwischen Praktikum, Anstellung, Selbstständigkeit? Wohin könnte ich ihm einen vereinbarten Stundensatz überweisen? Könnte er mir eine Rechnung schreiben? Das waren Fragen, mit denen er überfordert war. Und er fühlte sich auch außerstande, sie mit seinem Jobcenter zu klären, denn dort spricht man eher kein Englisch.

Wie es sich ergab, rutschte die Priorität für mein Projekt im Verlauf der Tage, die wir per Email kommunizierten aus verschiedenen Gründen, die nichts mit Nour zu tun hatten, aber nach unten. Die Umsetzung war nicht mehr wichtig. Also auch nicht mehr die Beantwortung dieser Fragen für mich. Ich bot Nour daher alternativ an, er könne sich aber mit Code Katas des Coding Dojo der CCD-School schon einmal warmprogrammieren ;-) Ich würde ihm gern Feedback zu seinen Lösungen geben.

Dabei hätte es bleiben können. Aber dann ließ mich das Thema Flüchtlingswelle doch nicht in Ruhe und ich überlegte, ob ich mehr für Nour tun könnte. Also bot ich ihm an, einmal nach Güstrow zu kommen, wo er derzeit lebt. Mit einem Artikel in meinem Blog hoffte und hoffe ich, seine Sichtbarkeit als motivierten Softwareentwickler zu erhöhen. Vielleicht findet sich ja ein Unternehmen, dass für ihn einen Platz hat.

Nour ist derzeit 26 Jahre alt und hat seinen Bachelor in Information Systems Engineering mit Schwerpunkt in Software application development. Interessanterweise hat er den letzten Baustein zum Abschluss seines Studiums per Skype eingebaut. Denn zu dem Zeitpunkt war er schon nicht mehr in Syrien. Es war ihm einfach sehr wichtig, einen qualifizierten und international relevanten Abschluss trotz aller Widrigkeiten zu schaffen. Denn eines war klar: Wo immer er aufgenommen würde, er will arbeiten, seinen Lebensunterhalt selbst verdienen und sich weiterentwickeln.

Das Gepäck, dass er, seine zwei Brüder und seine Eltern aus Damaskus mitnehmen konnten, war naturgemäß klein. Der Vater hatte sein Geschäft verkauft, um die Flucht finanzieren zu können. Was nicht in einen Rucksack und einen Koffer pro Person passte, musste zurückgelassen werden.

Aber Nour hatte nicht nur seinen Laptop eingepackt, sondern auch C# 2.0 - The Complete Reference, d.h. das für ihn beste verfügbare Buch zum .NET Framework. Dieses seitenstarke Buch sollte ihm in den folgenden Monaten ein treuer Begleiter sein.

Als ich in seine Wohnung in Güstrow komme, sehe ich es gleich auf der Fensterbank liegen. Dass er es durch alle Strapazen der Flucht behalten hat, beeindruckt mich. So sieht Lernwille aus.

Begonnen haben Nour und seine Familie die Flucht wohl Ende 2013. Auslöser war sein bevorstehender Studiumsabschluss. Er musste fürchten, danach von der syrischen Armee eingezogen zu werden. Eine Aussicht, die ihm Angst machte, da er für dieses Regime nicht Gefahr laufen wollte, sein Leben zu opfern. Aber auch die Alternative, bei einer der vielen Gruppen von Freiheitskämpfern zu dienen, war für ihn keine Option. Im Verlauf unseres Gesprächs berichtet er davon, wie Freunde von ihm auf dieser Seite gefallen waren - und wofür? Es war nicht einmal klar, ob die jeweilige Gruppe wirklich etwas für das Volk getan hatte oder nur für eigene Vorteile.

Darüber hinaus wäre seine Familie aber auch nicht sicher vor Übergriffen der einen oder anderen “Armee” gewesen. Er berichtete von Folterungen und Tötungen auch Unbeteiligter. Sich schlicht für Freiheit auszusprechen, birgt in Syrien ein hohes Risiko. Zum Beleg zeigte er mir ein Video in der arabischsprachigen “Parallelwelt” bei Youtube, auf dem Zivilisten brutal von Soldaten der regulären syrischen Armee zu Tode gebracht werden unter höhnischen Fragen, was sie nun zu ihrer Idee von Freiheit sagen würden. Nour übersetzte - und für mich war es kaum auszuhalten, das mitansehen zu müssen.

Dass Nour und seine Brüder sich in dieser Realität dafür entschieden haben, sich und ihre Familien in Sicherheit zu bringen… Wer würde ihnen das verdenken?

Der Plan war jedoch zunächst, nach Auflösung des väterlichen Geschäfts, nur in die Türkei zu flüchten. Das schien ihnen ausreichen weit entfernt und gleichzeitig immer noch heimat- bzw. kulturnah. Der Weg führte sie mit einer normalen Ausreise nach Beirut im Libanon, von dort mit einer Fähre nach Mersin/Türkei. Dort verbrachten sie einige Zeit, um dann nach Istanbul weiter zu ziehen.

image

Insgesamt lebten sie 7 Monate in Instanbul. Dort fing Nour an, Türkisch zu lernen und versuchte, Arbeit als Softwareentwickler zu finden. Leider ohne Erfolg.

Als das mitgebrachte Geld sich dem Ende zuneigte, sah die Familie keinen anderen Ausweg, als weiterzuziehen. Sie erkundigten sich, wo es größere Chancen auf Arbeit gebe. Deutschland und Schweden wurden als Ziele auserkoren.

Mit dem unverheirateten Bruder und einigen Freunden versuchte Nour, über die grüne Grenze nach Griechenland zu gelangen. Zweimal ohne Erfolg. Beim ersten Mal, weil die Gruppe getrennt wurde. Beim zweiten Mal, weil sie geschnappt wurden. Als er das berichtet, lacht er und sagt, “But it was fun!” Bei aller Ungewissheit und Angst sei es ja am Ende gut ausgegangen. Die türkischen Soldaten, die sie aufbrachten, waren nett, hatten zwar Hunde und Gewehre - aber nur zur Abschreckung. Geladen waren die Gewehre nicht.

Nach diesem Misserfolg ging es zurück nach Istanbul. Jetzt konnte nur noch eine Schlepperbande helfen. Für mehrere Tausend Euro pro Person wurde ein Transfer erkauft, der sie über Izmir, Bodrum, Marmaris in einen Lastwagen führte. Der brachte sie bei Nacht und Nebel irgendwo an der Küste zu einem Boot, das sie nach Kalymnos übersetzte.

Von dort nahmen sie eine reguläre Fähre nach Athen, wo er sein Flugticket nach Deutschland bekam. Das galt jedoch ab Kreta, von wo er schließlich nach Berlin gelangte. Seine Brüder folgten erst später.

Die Eltern nahmen derweil die Route Italien, Kopenhagen nach Schweden.

In Berlin angekommen suchte Nour sich mit Hilfe eines türkischen Taxifahrers ein Hotel - das der sogar bezahlte. Am nächsten Tag stellte er sich bei den Behörden vor und fand nach einem weiteren Monat seinen vorläufigen neuen Heimatort: Güstrow in Mecklenburg-Vorpommern.

Das war im September 2014. Nach Monaten in der Türkei und in Griechenland, nach Reisen zu Lande, zu Wasser und in der Luft war Nour angekommen. Die deutschen Behörden haben ihn “ins System” aufgenommen. Alles läuft seinen Gang. Nour lebt mit seinem Bruder in einer Wohnung. Nebenan wohnt der andere Bruder mit seiner Frau. Die Einrichtung ist bescheiden. Aber alle sind satt und warm.

Aber das war es dann auch schon.

Denn seit September 2014 ist nichts mehr passiert. Das Jobcenter verwaltet Nour und seine Brüder, macht aber keine Angebote. Für August 2015 war ein Sprachkurs in Rostock in Aussicht gestellt - doch dann wurde das Zugticket dahin doch wieder gestrichen. Es würde demnächst ein Sprachkurs in näherer Umgebung beginnen. Welch verschenkte Chancen durch eine Wartezeit von mehr als 12 Monate auf einen simplen Sprachkurs!

Nour hat also in Deutschland ein Jahr lang im Grunde keine wirkliche Integration erfahren. Der Kontakt mit den Behörden ist umständlich, weil man dort kaum Englisch spricht. Er muss immer Bekannte um Vermittlung bitten. Während ich ihn besuche, klingelt die Postzustellerin mit einem Paket. Nur durch meine Vermittlung kann geklärt werden, was es damit auf sich hat.

Die Selbstversorgung klappt. Internet gibt es auch. Aber Kontakt besteht nur zu anderen Flüchtlingen - via Smartphone und Laptop. Ständig höre ich aus dem Nebenzimmer die Benachrichtigungstöne von Apps wie Skype, Whatsapp oder Viber.

Nours Hoffnung ist, einen Job als Entwickler in einer Großstadt zu bekommen. Berlin, Hamburg… das ist ihm egal. Er würde gern in C# arbeiten und eher serverseitig zu Web-Anwendungen beitragen. Doch auch das ist verhandelbar. Hauptsache es geht voran.

Das größte Problem für Nour und seine Brüder ist die Untätigkeit, die Langeweile. Güstrow ist auch wirklich keine Stadt, die mit Ablenkungsangeboten glänzt. Und da das Geld sehr knapp ist, sind Ausflüge in die weitere Umgegend nicht einfach.

Sein kleiner Bruder möchte weiter nach Schweden zu den Eltern. Aber Nour kann sich ein Leben in Deutschland gut vorstellen. Dass die Verhältnisse in seinem Heimatland eine Rückkehr nahelegen, sieht er nicht ab. Dort wieder angstfrei leben zu können, dort zum Wiederaufbau der Gesellschaft beitragen zu können, das ist sein Traum. Doch bis dahin will er hier für sich sorgen und etwas lernen.

In mehr als sechs Stunden Gespräch kommen wir aber irgendwie nicht dazu, mal etwas gemeinsam mit .NET zu machen. Eigentlich hatte ich gedacht, wir gehen eine kleine Aufgabe an, so dass ich mal Nours Arbeitsweise kennenlerne. Doch es gibt so viel zu fragen und zu erzählen. Außerdem will er mir noch ein syrisches Gericht servieren: Kichererbsen stundenlang gekocht mit Brotstücken in Spezialsoße nach Geheimrezept seines Vaters.

image

Da die Besorgung einer Zutat durch den Bruder etwas stockt, verschiebe ich meine Rückreise. Aber das lohnt sich, denn das Ergebnis von Nours Kochkunst ist sehr lecker.

Natürlich sprechen wir in der ganzen Zeit auch über Softwareentwicklung und sein Studium. Nour hat in Damaskus auch mit Java und C++ Erfahrung gesammelt. Doch C# hat ihm am Ende am meisten gefallen.

Und genauso natürlich kommen Kultur und Religion zur Sprache. Islam im Fernsehen ist etwas anderes als gelebter bzw. erzählter Islam von Praktizierenden.

Doch die unterschiedlichen Auffassungen in dieser Hinsicht sind am Ende unwichtig. Verbindend ist das gemeinsame Interesse an der Softwareentwicklung und vor allem an einem Leben, das von Sinn erfüllt ist und in Frieden sich entwickeln kann. Mehr sucht Nour nicht. Er möchte seine Interessen und Kenntnisse einbringen können.

Ich als Freiberufler kann ihm dabei nur begrenzt helfen. Selbst ein kleines Projekt hier und da sind ja nicht das, wonach Nour sucht. Wer könnte also mehr bieten? Wo ist ein Team, das noch etwas Verstärkung braucht? Wer kann pragmatisch helfen bei der Integration eines Kollegen aus dem fernen Syrien? Eine Email an mich genügt. Ich stelle gern den Kontakt zu Nour her. Der würde sich sehr freuen.

image