Ein Bild sagt mehr als tausend Worte…

Wer kennt sie nicht, die Figuren und Bilder von Bikablo!? In vielen Workshops und Präsentationen sind sie präsent. Wieso kennt sie jeder und wo kommen sie her? Kann ich das auch lernen? Wie kann ich meine Moderation auch so intuitiv ohne Worte gestalten?

Der Ursprung dieser Figuren findet sich in der kreativen Firma Bikablo®, dies sind Spezialisten für Visualisierungen und Visualisierungstrainings.

Bikablo Figuren

Ich habe die Coaches immer bewundert, wie sie in zwei Minuten beeindruckende Bilder an die Flipcharts gemalt haben. Die Bilder wirken immer kreativ und schick, dennoch erkennt jeder ohne viel Phantasie die Aussage dahinter. So ist das Sprichwort “Ein Bild sagt mehr als 1000 Worte” mit diesen Visualisierungen wieder einmal mehr bewiesen. Es ist auch klar, dass ein Meeting mit visueller Moderation weit motivierender auf die Teilnehmer wirkt als ein Vortrag mit nur textuellem Inhalt.

Ich persönlich zeichne gerne und untermale Beispiele oder Diskussionen mit Bildern. Leider ist mein zeichnerisches Talent nicht sehr ausgeprägt. Wenn ich bisher ein Bild ans Whiteboard gezeichnet habe, kamen oft Missverständnisse auf. Ich hatte mal einen Computer gemalt und bekam die Frage, was diese zwei Kästchen sein sollen. Das war zum einen peinlich und zum anderen frustierend.

Ich lerne visuelle Moderation

Nun durfte ich Ende Oktober an einem zweitägigen Noser Basic Training zur “visuellen Moderation” teilnehmen, der durch die Bikablo® Akademie entwickelt und durchgeführt wurde. Bikablo® bietet auch noch Trainings für Fortgeschrittene an. Jedoch waren meine Erwartungen an den Basic Kurs erst einmal relativ simpel. Ich möchte Tipps und Tricks sowie Beispiele für eine Darstellung von immer wiederkehrenden Figuren. Ich möchte diese bei Meetings, Diskussionen oder Notizen verwenden und erhoffe mir, dass mich dann keiner mehr fragt, was diese Kästchen bedeuten.

In diesen zwei Tagen hat uns Kirsten Reinhold, Dipl. Designerin, Visual Facilitator + Visualisiererin von Bikablo®, gezeigt, wie man mit einfachen Formen tolle Figuren schnell, ansprechend und aussagekräftig zeichnen kann und auf was beim Zeichnen zu achten ist. Sie hat uns noch einmal eine kurze Farbenlehre erteilt, gezeigt welche Effekte so ein Schatten mit dem legendären Schattenstift bewirkt und wie man seine Schrift verbessern kann. Zusätzlich ist auch wichtig, dass man während dem Visualisieren sich überlegen muss, welches Objekt den Rahmen oder Platz vorgibt und mit welchem man beginnt.

Einen guten App-Tipp hatte Kirsten auch noch für uns. Mit der Office App “Office Lens” können Visualisierungen auf Whiteboards oder Flipcharts abfotografiert werden und die App bearbeitet diese gleich mit einem Weissabgleich. So können Bilder direkt digital weiterverwenden werden und werden nicht auf dem Flipchart beerdigt.

Wir waren alle sehr erstaunt, wie gut das Gelernte bei uns Teilnehmern bei den Übungen klappt. Unser Fortschritt überraschte uns alle, denn unsere Visualisierungen wirkten schon viel eindrucksvoller als noch anfangs des Workshops. Wir waren sehr motiviert, unsere neu gefundenen Talente im Alltag zu integrieren.

“Baby kommt” Prozess mit Bikablo Figuren

Was hat sich nach dem Kurs geändert?

Vor dem Kurs habe ich oft Notizen gemacht, die nur für mich alleine verständlich waren. Die Struktur, Schrift und Abkürzungen waren nur für mich bestimmt.

Seitdem Kurs versuche ich meine Notizen gleich so zu gestalten, dass sie auch als Dokumentation oder Diskussionsgrundlage verwendbar sind oder als Verständnishilfe bei Anforderungen angehängt werden können. Mir haben die Inputs, wie ich die einzelnen Punkte und Elemente auf dem Blatt strukturiere und bündeln kann, enorm geholfen um meine Gedanken sortiert auf Papier zu bringen. Dadurch ist der zeitliche Mehraufwand gering, jedoch gewinne ich die Wiederverwendbarkeit. Somit kann ich zum Beispiel bei späteren Diskussionen wieder auf meine Notizen zurückgreifen. Aber natürlich sind meine Notizen nicht perfekt, jedoch “Übung macht den Meister” – und mit der Übung werde ich sicherer und schneller. Zudem wende ich die Visualisierung nun auch nach Meetings an und halte so Diskussionsentscheide für Dokumentationszwecke fest. Zusätzlich hat die Visualisierung einen positiven Nebeneffekt für mich, Dokumentieren macht jetzt auch Spass.

Mein Visualisierungsfortschritt

Jazz ist nicht nur eine Musikrichtung,

sie kümmert sich auch um Software Projekte.

Jazz ist eine von IBM entwickelte CLM Plattform. Dort können Requirements, Issues (Tasks and Defects) und Dokumentationen auf einer Plattform verwaltet, verlinkt und in verschiedenen Project Areas verwendet werden. Eines der Anwendungen ist das IBM Rational Team Concert (RTC), welches sich um all die Themen kümmert, die in der Software Entwicklung vorkommen:
Iterations und Release Planung, Change Management, Defects Überwachung, Source Control und Build Automation (RTC Build). Jazz bietet eine grosse Möglichkeit an kundenspezifischer Konfiguration. Es eignet sich gut um das agile Framework SAFe 4.0 einzusetzen. Erwähnenswert ist auch, dass Jazz bis zu 10 Nutzern kostenlos ist.

RTC build

Vor kurzem durfte ich in einem neuen Projekt einen Build Server mittels der Jazz Build Engine (JBE) einrichten. Das war für mich ein komplett neues Thema und auch eine Herausforderung. Bisher war ein Build Server immer vorhanden und ich musste nur prüfen, dass er nach meinem Checkin weiterhin fehlerlos durchlief. Dadurch musste ich mich in einige Themen neu einarbeiten oder war auf vorhandenes Know How angewiesen. Trotz der aktiven Jazz Community war die Lösungsfindung für meine .Net – Jazz (JBE) spezifischen Fragen sehr langwierig.

RTC-Plugin für Eclipse

Um die Build Definition für die Jazz Build Engine zu konfigurieren, stellt Jazz ein RTC-Plugin für Eclipse bereit. Dies unterstützt dabei, die benötigten Pfade und anderen Properties zu definieren, wie zum Beispiel die Email Notifications, der Build Scheduler, Pre- und Post Build Events und das Nutzen von Test Frameworks.

Build Server konfigurieren

Auf dem Build Server müssen die benötigten Versionen verfügbar sein:

Nachdem der Build lief, wandte ich mich unseren Unit Tests zu und damit kam für mich eine richtig harte Nuss. Beim Test Framework haben wir uns vorerst für MSTest entschieden. Wir hatten uns auch nunit3 angesehen, jedoch haben uns die Vorteile von MSTest für unser Projekt überzeugt. Das RTC-Plugin bietet eine scheinbar einfache Konfiguration für MSTest an, der Build Server hatte es schon einsatzbereit und ein Schwesterprojekt setzt es schon erfolgreich ein.

Nach einiger Recherche habe ich herausgefunden, dass die benötigte .vsmdi Datei, welche das RTC-Plugin forderte, veraltet ist und es keine neuere Möglichkeit für MSTest in dieser Konfiguration gibt. Nun haben wir im Team noch einmal diskutiert, ob wir nicht doch auf Nunit wechseln sollten. So ergab sich ein neuer Anlauf mit Nunit3, aber auch hier stellt uns das RTC-Plugin vor eine verschlossene Türe – es fordert das «nunit configuration test file».

Als erster Link unter google für «nunit configuration test file» erscheint die nunit.org Seite, die gleich darauf hinweist, dass dieses config file veraltet ist und nicht für nunit3 gilt.

Nun war die Frage, sollen wir wegen unserem Build Server auf ein veraltetes Test-Framework bauen?

Die Antwort war «Ant».

Ant Script für RTC build

Anstatt bei der Build Definition Microsoft Build auszuwählen, bietet das RTC-Plugin auch eine Ant Configuration:

In dieser Configuration wird ein Ant Script erwartet. Mithilfe dessen werden abhängige und unabhängige Prozesse/Tasks gestartet. Nun braucht man nur noch ein Ant Script, welches all diese Tasks beinhaltet. Die Tasks kann ich in einzelne Targets und Activities unterteilen, so dass in der RTC Weboberfläche der Buildprocess in Schritten dargestellt wird. Wie im unteren Bild dargestellt, sehen wir so die einzelnen Tasks und die Zeit der Ausführung. Falls ein Task fehlschlägt, wird dieser gekennzeichnet und wir sehen sofort wo ein Problem besteht.

Wir nutzen nun das Ant Script um nuget packages zu laden, npm packages zu installieren, unsere Projekte zu builden und nunit Tests durchzuführen. Hätten wir noch MSTest Tests, könnten wir diese auch darüber starten.
Nachdem die nunit Tests durchgelaufen sind, kann das Resultfile ins Repository geladen werden. Die Weboberfläche im Build zeigt dann das Ergebnis an.
Die nunit Tests generieren jedoch xml Dateien, welche nunit Syntax enthalten. Die JBE versteht aber nur Junit. Damit die JBE das Ergebnis auch interpretieren kann, gibt man eine Übersetzungsdatei (.xslt) im commando an, so konvertiert nunit3 die Ergebnisdatei zu einer junit xml.

Ein Nachteil für uns mit Ant Script ist, dass man jedes Test Projekt einzeln aufrufen muss. Deswegen müssen wir das Ant Script bei jedem neuen nunit Test Projekt erweitern. Momentan ist es für uns keine Option, die Liste mit einer Wildcard auszutauschen, da wir noch nicht alle Test Projekte über den Automation Build starten möchten.

Hier ein Beispiel, wie der Aufruf der nunit3-console.exe im Ant Script aussehen kann:

<property name="nunit.transformedfile" value="junitout.xml"/>
<property name="nunit.transformation" value="nunit3-junit.xslt"/> 
<property name="nunit.resultfile" value="testresults.xml"/> 


<startBuildActivity activityIdProperty="runNunitTests"
      label="run nunit runNunitTests..."
      buildResultUUID="${buildResultUUID}"
      repositoryAddress="${repositoryAddress}"
      userId="${userId}"
      passwordfile="${passFilePath}" />

<exec executable="C:/.../nunit-console/nunit3-console.exe" failOnError="false">
	<arg value="com.asdf.qwe.Unit/bin/RTCConfig/qweTest.dll" />
	<arg value="com.asdf.asdf.Unit/bin/RTCConfig/asdf.Unit.dll" />
	<arg value="com.asdf.asdf.Test/bin/RTCConfig/asdf.Test.dll" />
	<arg value="--result:${nunit.transformedfile};transform=${nunit.transformation}" />
</exec>

<junitLogPublisher filePath="${nunit.transformedfile}"
			 buildResultUUID="${buildResultUUID}"
			 repositoryAddress="${repositoryAddress}"
			 userId="${userId}"
			 passwordFile="${passFilePath}" /> 

<delete file="${nunit.transformedfile}"/>

<completeBuildActivity activityId="${runNunitTests}"
      buildResultUUID="${buildResultUUID}"
      repositoryAddress="${repositoryAddress}"
      userId="${userId}"
      passwordfile="${passFilePath}" />
</target>

Links..

Der erste Einstieg für mich waren diese zwei Seiten: How To Use Jazz Ant Tasks For Microsoft VisualStudio und Continuous Integration with Rational Team Concert and Microsoft Visual Studio
Und eine gute Unterstützung für das Ant Script war dann folgender Blog: Getting Started with Ant scripts and RTC Build Ant Tasks

Wäre mir eher bewusst geworden, dass ich Ant für mein Problem einsetzen kann, hätte ich mir einige Zeit und Nerven gespart. Aber man lernt ja nie aus und wächst mit seinen Herausforderungen, die einem Noser Engineering ermöglichen ;-).