4Max/shutterstock.com

09. September 2011 / von Florian Kraus

Accso
Workshop
2011 –
BeST

Der erste Accso-Workshop zum Thema ‘Beschleunigte Softwaretechnik’ fand am 26. und 27. August 2011 statt. Zwei spannende Tage mit vielen Highlights…

Die Firma Accso schaut auf ein sehr erfolgreiches erstes Jahr zurück. In dieser Zeit haben wir zahlreiche neue Kunden gewonnen, aber auch begonnen, die technologische Grundlage unseres Geschäfts, die Beschleunigte Softwaretechnik, zu entwickeln und in ersten Projekten zu erproben.  Zeit, das bereits Geschaffene einmal Revue passieren zu lassen und die Perspektive für die nächsten Jahre zu entwerfen.

Am letzten August-Wochenende 2011 haben sich die Mitarbeiter der Accso deshalb zu einem zweitägigen Workshop im Taunus zusammengefunden. Am ersten Tag galt es in Diskussion und Brainstorming den Rahmen für die weitere technologische Entwicklung von Accso abzustecken. Mehrere spannende Vorträge namhafter Speaker (Adam Bien, Stefan Roock und Markus Völter) im Kontext ‘Beschleunigung’ gaben uns Inspiration für die Konzeptarbeit und reichlich Diskussionsstoff für die nächste Zeit.

Der zweite Tag stand ganz im Zeichen des Teambuilding der inzwischen auf über dreißig Mitarbeiter gewachsenen Mannschaft. In einem spannenden Parcours haben wir diverse trickreiche Aufgaben gemeinsam geplant und gelöst und gezeigt, dass wir effektiv zusammenarbeiten. Danach haben wir in einer GPS-gestützten Geocaching-Tour bewiesen, dass wir auch unter schwierigen Rahmenbedingungen (Dauerregen) Arbeitspakete effizient abarbeiten und das Ziel nicht aus den Augen verlieren.

Efficiency is the key to success? Beschleunigte Softwaretechnik, was ist das eigentlich…

Zum Einstieg in den Workshop führt Geschäftsführer Markus Voß uns durch die gedanklichen Grundlagen der Beschleunigten Softwaretechnik. Er macht klar, dass Accso im Wettbewerb mit einem klaren und differenzierenden Leistungsmerkmal operieren muss und das ist die Effizienz in der Softwaretechnik.

Hierbei erfassen wir Softwaretechnik ganzheitlich. Neben den agilen Vorgehensweisen betrachten und steuern wir in gleichem Maße die Effizienz-Aspekte von Methoden, Material und Werkzeugen und deren Abhängigkeiten über den gesamten  Software-Lebenszyklus. Der Mehrwert gegenüber dem üblichen Vorgehen entsteht dabei gerade auch durch die Beziehungen zwischen den verschiedenen Aspekten, z.B. Vorgehen und Architektur. Wesentlicher Hebel hierfür sind erprobte Best-Practices, die uns befähigen, effizient zu arbeiten.

Effizienz bzw. Effizienzsteigerung verstehen wir ganz pragmatisch als die Optimierung des Verhältnisses aus Leistung und Aufwand, d.h. wir setzen uns zum Ziel, Lösungen für unsere Kunden günstiger, schneller und besser zu realisieren. Das ist unsere Interpretation von Beschleunigung. Die Werkzeuge hierfür sind Angemessenheit und Pragmatismus, wie sie bereits Vilfredo Pareto in dem nach ihm benannten Prinzip gefasst hat und die z.B. auch eine Grundlage für die Interpretation des Agilen Manifests liefern.

Dieser hohe Anspruch muss natürlich von einem hervorragenden Team getragen werden. Wir haben viele Menschen im Team mit sehr viel Erfahrung zum state-of-the-art der Softwaretechnik. Darüber hinaus haben wir Agilität und Pragmatismus ‘im Blut’, denn wir haben in vielen Projekten erlebt und erprobt, was effizient ist und was nicht. Auf diesen Fundamenten bauen wir die Beschleunigte Softwaretechnik auf als unsere Art zu arbeiten und unseren Weg, erfolgreich Software-Projekte umzusetzen.

Acceleration is founded on best practice: das BST-Framework

Aufbauend auf diesem gedanklichen Rahmen geben uns die beiden Cheftechnologen von Accso, Thomas Jäger und Martin Lehmann, eine Gesamtsicht auf die im ersten Jahr erfolgten konzeptionellen Arbeiten zur Umsetzung der Beschleunigten Softwaretechnik (BST). Die Ergebnisse dieser Arbeiten bündeln wir unter dem Dach des sogenannten BST-Frameworks, das uns erlaubt, unser umfangreiches Wissen und Können zu erfolgreicher und effizienter Softwaretechnik aufzubereiten,  aktiv zu gestalten und effektiv und individuell in Projekten einzusetzen.

Das BST-Framework betrachtet dabei alle Domänen der Softwaretechnik ganzheitlich: In den Domänen Analyse, Architektur, Entwicklung, Test, Umgebung und Projektmanagement fassen wir unsere Best Practices in Form von Anleitungen, Aufgaben, Rollen, Konzepten und Referenzen zusammen. Dabei hat ‘Best’ immer nur für einen bestimmten Projektkontext Gültigkeit, eingesetzte Varianten werden explizit ausgewählt und erfolgreiche Practices werden dokumentiert. Die übergreifende Domäne Vorgehensstrategie bildet die Klammer und dokumentiert Reihenfolgen, Abhängigkeiten und Parallelitäten.  Darüber hinaus unterstützt uns das BST-Framework dabei, innovative Themen der Softwaretechnik zu entwickeln und somit Technologie- und Innovationsmanagement eng vernetzt zu betreiben.

Wir sind uns dabei wohl bewusst, dass ein großer Teil des Wissens zu Projektdurchführung und Technologien laufender Änderung unterlegen ist. Dementsprechend ist das BST-Framework leichtgewichtig, fokussiert, konkret und einfach adaptierbar. Da es durch die Projektarbeit des Teams mit Leben gefüllt wird – durch ständigen Einsatz und laufende Retrospektive – werden wir es nahtlos in unsere Werkzeugkette integrieren. Somit wird BST unseren selbst gesetzten Leitplanken der Beschleunigten Softwaretechnik – Angemessenheit, Pragmatismus und Team-Orientierung – gerecht.

Less is more: Stefan Roock über Agilität und Architektur

Im Anschluss konfrontiert uns Stefan Roock von it-Agile mit einem Spannungsfeld, das uns allen aus der Projektarbeit wohl bewusst ist, aber bisher noch nicht so explizit und pointiert betrachtet wurde: Agilität und (gute) Architektur scheinen schwer unter einen Hut zu bringen. Stefan Roock zeigt uns am Beispiel von Scrum, wie Prinzipien eines leichtgewichtigen Architekturentwurfs in agilen Projekten erfolgreich integriert werden können.

Nach einem kurzen Überflug über die Grundideen und Prinzipien von Scrum gibt er eine klare Abgrenzung, was Scrum ist und und was nicht. Er macht uns deutlich, dass Scrum eine deutliche Verschiebung der Sichtweise auf Softwareentwicklung bedeutet. Der Kunde muss den gedanklichen Schritt vom ‘Low Trust’-Ansatz (z.B. V-Modell) zum ‘High Trust’-Ansatz bewältigen. Aus Sicht des IT-Dienstleisters erfordert Scrum den Übergang von der Projektsicht hin zur Produktsicht und erfordert ein neues Denken von Rollen und Verantwortlichkeiten (z.B. von der Weisungsbefugnis hin zur Selbstorganisation). Stefan Roock macht deutlich, dass Scrum ein erweiterbares Framework ist, dass zwar grundsätzlich auf die bewusste Beschränkung auf wenige Rollen, Artefakte und Meetings baut, man sich daran aber nicht sklavisch halten muss. Insbesondere muss das Entwickler-Team nicht zwingend homogen sein: Spezialisierungen, aber auch Kombination von Rollen sind möglich, sofern wenige Restriktionen beachtet werden (z.B. Scrum Master ungleich Product Owner).

Auch im Bereich der Architektur plädiert Stefan Roock für bewusste Selbstbeschränkung. Er stellt das der Umsetzung vorgelagerte ‘Architektur-Envisioning’ als pragmatisches Werkzeug vor, um eine angemessene architektonische Basis zu schaffen. Dieses Envisioning sollte nur diejenigen Entscheidungen treffen, die später nicht mehr oder nur unter großem Aufwand änderbar sind, also die grundsätzliche Charakteristik des zu bauenden Systems, den Architekturstil und die Technologie. Er empfiehlt, diese Phase auf wenige Tage zu begrenzen und warnt explizit davor, sie für Fachkonzeptarbeit, Technologiebewertung oder gar ein Komponentendesign zu missbrauchen.

Mit dem Envisioning ist die Architekturarbeit allerdings auch im Scrum-Projekt nicht abgeschlossen. Der herausfordernde Teil der Aufgabe besteht darin, die wesentlichen Gedanken und Leitplanken der Architektur ohne eine imperative Architektenrolle durch die Laufzeit des Projekts zu tragen. Stefan Roock weist darauf hin, dass es einer gründlichen Ausbildung und sehr viel Erfahrung bedarf, eine Architektur über mehrere Architekturebenen (vom Architekturstil bis zur einzelnen Klasse und Methode) inkrementell zu entwickeln. Eine oder mehrere Personen mit diesen Fähigkeiten sind für den Erfolg, insbesondere von größeren Scrum-Projekten wesentlich. Er empfiehlt, hier das Ausbildungsproblem zu lösen, statt die Scrum-Idee durch imperative Vorgaben zu ersticken.

Die genannten Skills sind eine wesentliche Voraussetzung, um der drohenden Gefahr einer stark ansteigenden Aufwandskurve entgegenzuwirken. Denn die agile Grundidee von Scrum verhindert den steilen Kostenanstieg von Features mit der Projektlaufzeit nicht, der flexible Umgang mit Requirements kann ihn sogar beschleunigen. Diese Entwicklung abzuwenden, sieht er als Aufgabe des gesamten Scrum-Teams. Soll ein Scrum-Projekt zum Festpreis umgesetzt werden, ist dies natürlich für den Dienstleister auch wirtschaftlich existenziell und erfordert die Etablierung eines möglichst unabhängigen Product Owners. Hier kann die Doppelbesetzung der Rolle durch je einen Mitarbeiter von Kunde und Dienstleister hilfreich sein.

Schließlich präsentiert uns Stefan Roock unter dem Schlagwort “Architecture is a framework for change” eine Gesamtsicht auf Architektur in Scrum-Projekten, die sich aus den Aspekten  Architekturvision, Entwicklungspraktiken und Entwurfsprinzipien zusammensetzt. Er stellt uns die von Robert C. Martin entwickelten SOLID-Prinzipien vor und zeigt konkrete Einsatzbeispiele aus der Projektarbeit. Aus der Projekterfahrung zieht Stefan Roock den Schluss, dass sich die SOLID-Prinzipien und die uns wohlbekannten QUASAR-Architekturprinzipien sehr gut zu einem stabilen Rahmenwerk für Architektur in agilen Projekten ergänzen und die Erreichung einer flachen Aufwandskurve bestmöglich unterstützen.

Limit expressiveness: Markus Völter über MDx und DSL best practices

Markus Völter, Freiberufler und Mitarbeiter der Firma itemis, gibt uns einen Crash-Kurs zu modellgetriebenen Methoden und Domänenspezifischen Sprachen.

Zunächst stellt er die zwei zentralen Aspekte von DSLs heraus: Domänenspezifische Sprachen sind einerseits ein wesentlicher Faktor effizienter und effektiver Kommunikation und helfen bei einer klaren Strukturierung von Fachdomänen. Der wesentliche Hebel für die Entwicklungseffizienz liegt andererseits in der automatischen Ausführbarkeit (in der Kombination mit MDx-Prinzipien), sei es durch Generierung von ausführbaren Modulen oder der Interpretation der DSL zur Laufzeit. Um das Effizienzpotenzial auch wirklich zu heben, müssen aber einige Grundregeln beachtet werden, die Markus Völter in Form von Best Practices präsentiert und mit praktischen Beispielen unterlegt.

Eine Grundvoraussetzung für den Einsatz von DSLs zur Abbildung fachlicher Domänen ist die Bereitschaft einer Fachabteilung, sich auf eine formale Sprache einzulassen und Anforderungen nicht auf dem klassischen und unscharfen umgangssprachlichen Wege sondern auf der Ebene des formalen Sprachbaus zu definieren. Dies erfordert intensive Zusammenarbeit und klare Kommunikation zwischen dem Fachmann und dem Sprachkonstrukteur und wird besonders gut mit Kunden funktionieren, die in ihrer Geschäftswelt eher technisch oder formal orientiert denken und arbeiten. Dementsprechend sind viele der von Markus Völter genannten Praxisbeispiele bei Herstellern technischer Geräte (insbesondere bei Embedded-Systemen) oder im Finanzbereich angesiedelt.  Wenn das oben beschriebene Zusammenspiel aber funktioniert, ist dies aus Sicht von Markus Völter eine Alternative zur „klassischen“ Business Analyse.

Oft ist hier das ‘Enabling’ der Fachexperten ein wesentlicher Faktor: Dem Experten muss vermittelt werden, dass er mit der DSL ein Werkzeug in die Hand bekommt, das es ihm erlaubt, seine Geschäftslogik wesentlich genauer zu formulieren, als  dies text- oder tabellenbasierte Werkzeuge ermöglichen. Hierzu sollte der Sprachbauer bei der Konstruktion der DSL auf eine sehr präzise und klare Notation achten, die so weit wie möglich den Ausdrucksgewohnheiten und Sprachmustern des Fachexperten entspricht. Darüber hinaus sollte man auf das Prinzip ‘Limit Expressiveness’ achten, und die Mächtigkeit der DSL bewusst einschränken um ihre Verständlichkeit, Erlernbarkeit und effektive Benutzbarkeit zu gewährleisten. Hier ist es durchaus sinnvoll und üblich, Rand- oder Spezialfälle der Fachlichkeit aus der DSL auszugrenzen und nachträglich zu programmieren. Sollen große Domänen über DSLs abgebildet werden, empfiehlt Markus Völter, diese in Viewpoints zu gliedern und für diese Sichten jeweils eigene DSLs zu konstruieren, was wiederum dem oben genannten Prinzip entgegenkommt.

Grundsätzlich sind textuelle Sprachen den graphisch orientierten DSLs überlegen, graphische  Interpretationen können aber als Hilfsmittel zur Visualisierung von Zusammenhängen wertvoll sein. Unabhängig davon sind die benutzten Werkzeuge ein wesentlicher Faktor für den erfolgreichen Einsatz. Natürlich können DSLs auch mit simplen Texteditoren entwickelt werden. Moderne Werkzeuge wie Xtext, MPS oder Intentional bieten vollständige integrierte Entwicklungsumgebungen, welche die gesamte MDx-Toolkette (Modellentwicklung, Modelltransformation, Codegenerierung) abdecken. Sie stehen den ‘klassischen’ IDEs kaum nach, sind mit diesen interoperabel und bieten spezifische und mächtige Features für die Sprachentwicklung an. Mittels dieser Werkzeuge sind auch nachträgliche Sprachänderungen in der Praxis kein großes Problem mehr, da entsprechende Refactoring-Mechanismen zur Verfügung stehen.

Markus Völter motiviert, warum aus seiner Sicht UML und BPMN ungeeignet sind für den Bau von Domänenspezifischen Sprachen. Er weist darauf hin, dass UML zu mächtig, zu generisch und zu ausdrucksstark ist, da UML ursprünglich als Modellierungssprache für die objektorientierte Softwareentwicklung definiert wurde. Noch spezifischer ist der Fokus von BPMN, das nur  für den Einsatz in der Geschäftsprozessmodellierung konzipiert wurde.

Schließlich empfiehlt Markus Völter noch den Aufbau und Einsatz von Architektur-DSLs, die in einem Bottom-Up Ansatz als Fundament von fachlichen DSLs dienen können, und demonstriert in diesem Zusammenhang einige konkrete Sprach- und Code-Beispiele.

Kill the bloat: Adam Bien über Pragmatismus in der Java-Entwicklung

Zum Abschluss des Vortragsteils präsentiert uns Adam Bien, Java Champion, JCP Expert Group Member und wohlbekannter Speaker zu vielen Themen aus der Java-Welt, einen unterhaltsamen Rundumschlag durch seine Erfahrungen als Problemlöser in schwierigen Java-Projekten. Er gibt uns anhand zahlreicher Anekdoten sehr konkrete Anhaltspunkte, warum  Pragmatismus und Besinnung auf Einfachheit und Angemessenheit in der Architektur und Umsetzung von Softwarelösungen essentiell sind.

Zunächst hält er ein (natürlich nicht vollständig objektives J) Plädoyer, warum Java ‚still rocks‘ und trotz der fortschreitenden Entwicklung dynamischer Sprachen Java und Java EE die Mittel der Wahl für die Entwicklung von Enterprise-Anwendungen sind. In einem kurzen Überflug ruft er uns die wesentlichen Features ins Gedächtnis, die Java seit seiner Einführung Anfang der 90er Jahre zur heute erfolgreichsten Programmiersprache machen und insbesondere dem ‚Nine-to-Five-Developer‘ das Leben erleichtern.

Dazu zählen die grundsätzliche konzeptionelle Einfachheit (‚Java is no magic‘), inhärente Spracheigenschaften wie Typsicherheit, Struktur und Lesbarkeit des Codes (‚no obfuscation ‘), hohe Performance, ausgereifte Compiler und schneller Roundtrip. Aber eben auch die Existenz von professionellen Entwicklungsumgebungen mit ausgereiften Code-Assist, Debug-, Profiling- und Refactoring-Möglichkeiten und integierten Werkzeugen zum Build-Management sowie die umfangreiche Dokumentation (Bücher, Tutorials, Blogs, Codebeispiele). Und nicht zuletzt zählen im Enterprise-Bereich produktionsrelevante Werkzeuge wie das JMX-basierte System-Monitoring (‚Maturity‘).

Diese Features gehören mittlerweile für die Mehrheit der Entwickler zum gedanklichen Standardrepertoire, werden aber gerade in neuen, dynamischen und Script-orientierten Sprachen nicht oder nur unvollständig unterstützt. Davon unabhängig sieht er die dynamischen Sprachen in speziellen Kontexten und Szenarien als wertvolle Ergänzung der Werkzeugpalette. Schließlich nennt Adam Bien noch die immense installierte Codebasis, die umfangreiche Akzeptanz und Unterstützung von Java durch viele Key-Player der Software-Industrie und  die umfangreiche Community (‚Adoption‘) als wesentliche Faktoren und prognostiziert, dass uns Java nicht nur noch sehr lange erhalten bleibt, sondern sein Marktanteil weiter wachsen wird.

Unter dem Stichwort Pragmatic Java und mit der nicht ganz ernst gemeinten Fußnote ‚Soll es Spaß machen oder funktionieren…?‘ gibt uns Adam Bien dann einen umfangreichen und mit konkreten Praxisbeispielen (und Low-Lights!) untermauerten Überblick über seine Best Practices für Design und Entwicklung von Java-Enterprise-Anwendungen.

Mit der Forderung  ‚Can you explain it to an alien‘ gibt er uns einen pragmatischen Maßstab für Angemessenheit und führt uns vor Augen, wie viel kostspieliger Unfug in der Softwareentwicklung aus purer Gewohnheit und einem Mangel an Reflexion getrieben wird. Er stellt klar, dass altgewohnte und teilweise quasi-religiös interpretierte Best Practices heute oftmals nicht mehr tragen und immer kritisch hinterfragt werden sollten (Stichwort ‚keine Fachlogik in der Persistenz…‘).

Adam Bien arbeitet an mehreren Beispielen heraus, dass Java unglücklicherweise die Neigung seiner Entwickler zum over-engineering fördert und dass gutes Design nicht an der Anzahl der Abstraktionsschichten zu messen ist. Plakativ zeigt er das an der häufig anzutreffenden Vorgabe ‚jede Klasse braucht ein Interface‘ und stellt klar, dass Interfaces in Java für zwei dedizierte Zwecke eingeführt wurden, nämlich für die Variation/Austauschbarkeit von Implementierungen und für die Dekoration von Funktionalität. Auch die massive Einführung von parallelen Objekthierarchien (Stichwort ‚Transferobjekte‘, ‚DAOs‘ etc.) unter der Maßgabe der Entkopplung hält er für ein Antipattern, insbesondere wenn diese durch die Verwendung von konfigurationsgestützten Mapping-Tools noch weitere Komplexität bei reduzierter Typsicherheit erzeugen.

Viele weitere gerne und oft unreflektiert eingesetzte Design-(Anti-)Patterns wie frühzeitige Optimierung (‚Caching von EJBs‘), willkürliche Verteilung (Auswirkungen von Eric Brewers Consistency-Availability-Partition-Theorem!) und dynamische Modularisierung (unbeherrschbare Komplexität und Unwartbarkeit ‚by design‘)  führt er uns vor Augen. Er kritisiert schlechte Entwicklungsangewohnheiten (‚XML ist kein Code, das muss man nicht testen‘ ‚wir dokumentieren jede Methode, auch die getter, weil Checkstyle das fordert‘) und entlarvt schließlich noch die gerne hochgehaltene Aussagekraft der Test-Coverage als gefährlichen Irrglauben.

Eine umfassende Schilderung würde hier zu weit führen würde und soll dem Live-Erlebnis eines Bien-Vortrags vorbehalten bleiben. Zum Abschluss gibt Adam Bien uns noch die drei Regeln ‚Think about propabilities…‘, ‚Always ask about the intentions…‘ und ‚Always question *-llities…‘ als Leitplanken für Angemessenheit und pragmatisches Design mit auf den Weg. Wir haben in dieser äußerst unterhaltsamen Stunde viel geschmunzelt und lauthals gelacht, nicht zuletzt auch hin und wieder in nachträglicher Selbsterkenntnis :-).

Gruppenarbeiten: Wie geht es weiter mit der Beschleunigten Softwaretechnik

Im Anschluss an den Vortragsteil nehmen wir uns einige Stunden Zeit für Diskussionen und Themenarbeiten. In mehreren Arbeitsgruppen beleuchten wir Aspekte der Beschleunigten Softwaretechnik und des BST-Frameworks, insbesondere im Hinblick auf die praktische Umsetzbarkeit in Kundenprojekten. Dabei können wir die aus den Vorträgen mitgenommenen Anregungen und Best Practices gleich gewinnbringend einsetzen.

Die Arbeitsgruppen präsentieren Ihre Ergebnisse anschließend im Plenum, wo die Ideen in der Gesamtsicht weiter diskutiert werden. Die Ergebnisse dieser Diskussionen sind wertvoller Input für die weitere Ausgestaltung und Umsetzung der Beschleunigten Softwaretechnik in den nächsten Monaten.

Mit einem gemeinsamen Abendessen, an dem auch unsere mittlerweile eingetroffenen Familien teilnehmen, lassen wir den Tag ausklingen.

Teambuilding I: Parcours

Die intensive und effektive Zusammenarbeit in Teams ist die Grundlage unserer Projektarbeit. Am zweiten Tag setzen wir uns deshalb zum Ziel, die Teamkompetenz der inzwischen auf über dreißig Mitarbeiter gewachsenen Mannschaft der Accso spielerisch auf die Probe zu stellen. Und da unsere Familien ja auch im Alltag (zumindest indirekt) einen wesentlichen Anteil an unserer Arbeit haben, sind sie natürlich mit von der Partie.

Ein professionelles Organisationsteam hat für uns einen spannenden Parcours im naheliegenden Wald vorbereitet. Es sind diverse trickreiche Aufgaben zu meistern, die sich hinter geheimnisvollen Namen wie ‘Der Sumpf’, ‘Die Spinne’ oder ‘Die Wippe’ verbergen. Keine dieser Aufgaben ist einfach, sie erfordern sorgfältige Analyse, Konzeption und Planung. In der Umsetzung ist Präzision im Detail gefordert, ohne das große Ganze aus den Augen zu verlieren. Und natürlich ist die Zeit begrenzt. Ohne gegenseitige Hilfestellung sind die Aufgaben also nicht zu lösen, effektive Zusammenarbeit ist der wesentliche Erfolgsfaktor.

Teambuilding II: Geocaching

Am Nachmittag meint es das Wetter nicht gut mit uns und beschert uns häufige und heftige Regenschauer. Das hält uns aber nicht davon ab, im zweiten Teil des Teambuilding-Programms eine Geocaching-Wanderung durch die umliegenden Wälder zu absolvieren. Geocaching  ist eine Art elektronische Schatzsuche oder Schnitzeljagd. Die Verstecke (‘Geocaches’, kurz ‘Caches’) werden anhand geographischer Koordinaten mit Hilfe eines GPS-Empfängers gesucht. Das Organisationsteam hat mehrere Routen für die Teams vorbereitet, wobei an verschiedenen Stationen Caches versteckt sind oder spannende Aufgaben zu absolvieren sind. Der Inhalt der Caches oder die Lösung der Aufgaben liefern jeweils die Koordinaten des nächsten Zwischenziels.

Verschiedene Kreuzwort- und Buchstabenrätsel, originelle und nicht ganz einfache Fragen (Smartphone und Google helfen…) sowie versteckte Zeichen auf Vogelbrutkästen und unter Brücken geben uns Hinweise für die weitere Route. Elektronische Bastelarbeiten bei strömendem Regen liefern uns Blinkzeichen, die in Koordinaten umgesetzt werden können. Darüber hinaus begleitet uns eine Menge  Geschichtliches rund um den römischen Limes auf unserem Weg. Geheimnisvolle Sirenenklänge (genauer gesagt: Klingelzeichen) aus einem  See und mystische Zeichen auf uralten Steinen führen uns immer näher ans Ziel. In allen Fällen hilft die Beherrschung der Grundrechenarten (oder des Taschenrechner des Smartphones) dabei, korrekte Koordinaten zu ermitteln und nicht in die Irre zu marschieren.

 

Den actiongeladenen Tag beschließen wir mit einem großartigen Abendessen in einer historischen Mühle. Der erste Workshop der Accso wird mit Sicherheit nicht der letzte bleiben und im nächsten Jahr seine Fortsetzung finden.

Autor

Florian Kraus Florian ist seit Januar 2011 als Principal bei der Accelerated Solutions GmbH beschäftigt und berät zu Themen im Bereich der Architektur und Integration von Anwendungssystemen, der Enterprise-Architektur und der serviceorientierte Gestaltung von Anwendungslandschaften.
Weitere Artikel

Das könnte Sie auch interessieren