Im eCommerce-Bereich von Thalia sind wir mittlerweile im Home Office. Unsere Entwicklungs-Teams, die Agile Coaches, alle Product Owner, die gesamte IT und natürlich auch alle TeamleiterInnen.
Unsere Organisation und die Art, wie wir arbeiten ist bisher auf Präsenz ausgerichtet. Wir haben unsere Räume so gestaltet, dass Menschen, die zusammen arbeiten auch zusammensitzen. Wir treffen Annahmen, dass teamübergreifende Zusammenarbeit besser funktioniert, wenn der persönliche Kontakt da ist. Wenn für die Klärung eines Problems maximal die nächste Etage besucht werden muss. Wenn das Treffen an der Kaffeemaschine (und wir haben wirklich gute Kaffeemaschinen) das Erstellen von JIRA-Tickets ersetzt. Wenn ein beiläufiges ‚kann mal jemand…‘ ein halbstündiges Meeting obsolet macht. Wenn bei der ausführlichen Bewertung des Tatorts (aka Bundesligaspiel, beliebiges Online-Spiel) am Montagmorgen auch Meinungen von ‚Über-den-Flur-Eilenden‘ gehört werden können.
Unser IT-Leitungsteam im Home Office.
Und jetzt haben wir Zoom. Und Slack. Und Telefonkonferenzen. Ach ja, und eMails.
Natürlich haben wir auch vorher schon diese
Kommunikationstechnologien genutzt. Aber sie waren, bei persönlicher
Kommunikation, eher die Ausnahme als die Regel.
Was wir schon ahnen:
Arbeiten nach agilen Werten und Vorgehensmodellen – das
hilft: Transparenz durch digitale Boards, Offenheit bei Feedbacks in auch mal
angespannten Situationen, Fokus auf die Umsetzung der richtigen Dinge und vor
allem: Auf Veränderungen zu reagieren. Und – yes indeed – wir haben es hier mit
einer Planänderung zu tun.
Crossfunktionale Teams, die selbstorganisiert ihre Produkte
entwickeln – sind sehr gut vorbereitet. Die klaren Strukturen der agilen
Vorgehensmodelle (z.B. Scrum), die gemeinsamen Ziele (Sprintziele oder
Roadmap-Themen der Teams) und die gelebte Selbstverantwortung helfen beim Operationalisieren
der Remote-Arbeit. Es ist weiterhin
klar, an welchen Themen wie gearbeitet wird. Das Vakuum der
Orientierungslosigkeit ist sehr gering.
Was wir noch nicht wissen:
Wie sich eine mehrwöchige Home Office-Phase auf die Organisation auswirkt:
Wie verändert sich unsere Art zu kommunizieren?
Werden wir weniger effizient?
Entstehen mehr Missverständnisse insbesondere in der teamübergreifenden Zusammenarbeit?
Und werden wir mehr oder weniger Spass an unserer Arbeit haben?
Aktuell kann ich sagen: Alleine ist man weniger zusammen und das kann auch die Anzahl und Häufigkeit von Slack-Nachrichten nicht wirklich ändern.
Both sides of the story – Thalia in Zeiten von Corona
Auch Thalia hat die Corona-Krise getroffen. Und das in ganz unterschiedlicher Form. Unsere stationären Buchhandlungen sind geschlossen, das eCommerce hat aktuell Konjunktur und die Art, wie wir arbeiten hat sich praktisch von einem auf den anderen Tag verändert.
Waren wir gut vorbereitet? Schwierig, die Frage mit ‚Ja‘ zu
beantworten. Das würde implizieren, dass wir mit so einem Szenario gerechnet
hätten. Haben wir nicht, wie wahrscheinlich auch der Rest der Welt.
Aber können wir von Technologien, Strukturen und Arbeitsweisen profitieren, die wir uns in den letzten Jahren angeeignet, die wir geübt haben? Zumindest diese Frage können wir nach 3 Wochen zumindest vorsichtig optimistisch bejahen.
In den kommenden Wochen wollen wir in kleinen Beiträgen berichten, wie wir als OmniChannel-Händler, als eCommerce-Unternehmen, als Tech-Firma – eben als Thalia, mit dieser Ausnahmesituation umgehen.
Um eine bessere Code Qualität an unseren Softwareprodukten zu gewährleisten haben wir uns im Unternehmen entschlossen eine statische Code Analyse einzuführen. Ein besonderer Augenmerk liegt hierbei auf der Code Coverage und das Einhalten von zuvor festgelegten Programmier-Richtlinien.
In diesem Artikel geht es um das Erstellen+Anzeigen von Testreports auf einem SonarQube Server mittels Jenkins, um das Herunterladen+Anzeigen dieser in Android Studio und um das Anzeigen von lokalen, neuen SonarQube Issues. Desweiteren wird noch kurz auf die SonarQube-Benutzer-Oberfläche eingegangen.
SonarQube ist ein Tool für die statische Code Analyse. Hierfür werden zuvor erstellte Test Reports von SonarQube eingelesen und nach bestimmten Richtlinien und Regeln ausgewertet.
Vorbereitung des lokalen Projekts
Zuerst muss das Android-Projekt so konfiguriert werden, dass es Jacoco Test Reports erstellt. Dafür wird eine jacoco.gradle Datei erstellt:
In dieser Datei wird der Gradle-Task zur Erstellung des Test-Reports angelegt und die entsprechenden Pfade für die Source- und Class Dateien für die Java- und Kotlin Klassen angegeben.
In der build.gradle Datei des Moduls muss dann noch die jacoco.gradle Datei hinzugefügt werden.
Zum Schluss müssen noch einige Konfigurations-Einstellungen für Sonar in den gradle.properties angegeben werden.
Nun können mit den folgenden Gradle-Tasks die Test-Reports erstellt werden.
Build – baut das Projekt und generiert die benötigten Class-Datein
testDebugUnitTest – führt die Tests aus und erstellt einen jacoco Test-Report (modul/build/jacoco/testDebugUnitTest.exec)
jacocoTestReport – erstellt die Test-Reports im HTML Format (modul/build/reports/jacocoTestReport/)
Es
kann auch nur der jacocoTestReport-Task ausgeführt werden, da dieser
eine Abhängigkeit zu den anderen Tasks beinhaltet. Bei einem cleanen
Projekt benötigt dies aber mehr Zeit.
Nach dem Ausführen der Gradle-Tasks liegen die Reports im Modul-Ordner unter build/reports/jacoco/TestReports im HTML-Format vor und können im Browser angezeigt werden.
Vorbereitung des Jenkins-Servers
Um sich die Reports im Sonar an zu schauen, kann man diese über den Jenkins-Server zu Sonar übertragen. Im Jenkins muss zuerst das Sonar-Plugin installiert werden, bei dem die URL des Servers eingetragen wird und der Sonar Runner ausgewählt werden.
Die Einstellung für das Sonar-Plugin finder man unter: Manage Jenkins -> Configure System -> SonarQube
Die Einstellung für den Sonar-Runnar befindet sich unter: Manage Jenkins -> Global Tool Configure -> SonarQube Scanner
In dem Jenkins-Job müssen dann noch die folgenden Gradle-Tasks eingetragen werden:
Anschließend wird der SonarQube Scanner konfiguriert. Hier muss die Datei mit den Properties für Sonar angegeben werden.
Nun wird jedes Mal, wenn der Jenksins-Job für das Projekt ausgeführt wird, auch der Sonarqube Scanner ausgeführt und veröffentlicht seinen Report auf dem SonarQube-Server.
Benutzeroberfläche des Sonar-Servers
Damit Sonar die Testreports empfangen kann und diese korrekt angezeigt werden, müssen hier noch das SonarKotlin-, das SonarJava- und das Git-Plugin installiert werden.
Auf der Startseite von Sonar werden alle Projekte aufgelistet und eine Übersicht der Analyse angezeigt.
Klickt man auf ein Projekt, werden detailliertere und zusätzlich Informationen angezeigt. Man kann die Analyse in 2 Kategorien einteilen. Das sind zum Einen Messungen (Code Coverage, Duplication) die SonarQube anhand des Codes durchführt und zum Anderen Issues (Bugs, Vulnerabilities, Code Smells), die durch Verletzung von zuvor festgelegten Code Richtlinien auftreten. Eine zusätzliche Richtlinie kann man für ein sogenanntes Quality Gate festlegen. Dies kann zum Beispiel eine Mindestanforderung von der Code Coverage des neu entwickelten Codes sein.
Über die einzelnen Analyse-Kategorien gelangt man zu einer detaillierten Ansicht der einzelnen Issues oder Messungen.
Für
Android-Studio gibt es das SonarQube Community Plugin, welches 2
Funktionen mit sich bringt:
Anzeigen von vorhandenen Issues vom Sonar-Server
Anzeigen von neuen Issues mittels einer lokalen Projekt-Analyse
Vorhandene Issues vom Sonar-Server
Um sich die vorhandenen Issues vom Server herunterzuladen, muss das Plugin zuerst konfiguriert werden. Hierzu ruft man dieses in den Einstellungen von Android-Studio auf und trägt den Sonar-Server ein. Anschließend wählt man das Projekt in dem Abschnitt Resourcen aus.
Unter dem Reiter Analyse -> Inspect Code muss in dem Inspection Profile SonarQube ausgewählt werden. Nun werden bei der Code Inspection die Sonar-Issues vom Server heruntergeladen und in der IDE angezeigt.
Lokale Projekt-Analyse mit dem Sonar-Gradle-Plugin
Um das lokale Projekt nach Sonar-Issues zu analysieren muss zunächst das SonarQube-Script konfiguriert werden. Hier muss der Sonar-Gradle-Task und der Pfad zum sonar-report eingestellt werden. Der Sonar-Report ist vor dem ersten Ausführen noch nicht vorhanden, da er erst durch den Gradle-Task erstellt wird.
Als nächster Schritt muss lokal SonarQube konfiguriert werden. Hierzu wird zuerst in der build.gradle Datei des Projekts sonarQube als Dependencie hinzugefügt.
In der build.gradle Datei des Moduls wird SonarQube dann applied und konfiguriert.
Nachdem SonarQube konfiguriert wurde, kann das Projekt unter Analyze -> Inspect Code analysiert werden. Hierzu muss nur noch das Sonar-Profile (mit Sonar Issues + new Sonar Issues) ausgewählt und mit OK bestätigt werden.
Nach der Analyse werden die Sonar-Issues vom Server und die aus der lokalen Analyse unten im Reiter Inspection Results angezeigt.
Neu gefundenen lokalen SonarQube Issues werden zusätzlich noch in einem kleinen Popup unten rechts von Android Studio angezeigt.
Nach der Einführung von SonarQube in unser Android-Projekt haben wir eine zentrale Anlaufstelle für unsere Code Qualität und kontrollieren regelmäßig diese in der SonarQube-Benutzer-Oberfläche. Desweiteren bekommen wir über Jenkins ein schnelles Feedback ob unser Quality Gate eingehalten wurde. Mit dem Community-Plugin laden wir uns die SonarQube-Issues vom Server herunter und beheben diese direkt in Android Studio. Bevor wir ein Feature pushen, kontrollieren wir mittels des Plugins im Vorfeld das Einhalten der Programmier Richtlinien und können neu aufgetretene Issues direkt in Android Studio beheben.
Hackathon 2019 in Berlin
Unseren 3. Hackathon haben wir im Juni 2019 zusammen mit unserem B2B-Partner Douglas ausgerichtet. An zwei Tagen pitchten wir mit 25 Teilnehmern Ideen, probierten neue Methoden und Techniken aus und teilten unser Wissen. Das alles gut versorgt, mit jeder Menge Spass und Motivation. Mit dem Thema Personalisierung haben wir den Hackathon dieses Mal inhaltlich geschärft. Das Publikum hat nach den Abschluss-Präsentationen zwei Projektideen prämiert und die Gewinner durften sich über tolle Preise freuen. Über die Themen und Eindrücke möchten wir euch über unseren Techblog teilhaben lassen.
Thalia B2B-Entwicklung in Berlin In Berlin entwickeln wir seit 2014 für B2B-Partner digitale Produkte im Retail-Umfeld. In der kontinuierlichen Produktentwicklung sind uns agile Arbeitsweisen und stabile Teams sehr wichtig. Unser Schwerpunkt liegt in der Frontend-Entwicklung für mobile Geräte auf Basis von Android und iOS.
Teilnehmer und Partner beim gemeinsamen Abschlussfoto – Yeahh! 🙂
Vanessa Stützle – Managing Director Ecommerce & Omnichannel Douglas Group begrüßte die Teilnehmer mit einer Videobotschaft
Personalisierung – Unser Schwerpunktthema
Mit unseren Teams in Berlin entwickeln wir seit mehreren Jahren erfolgreich Apps für unseren B2B-Partner Douglas. In Absprache mit Douglas haben wir den inhaltlichen Schwerpunkt auf das Thema Personalisierung gelegt und uns überlegt, wie wir diesbezüglich Projektideen generieren können. Die Teilnehmer haben wir vorab mit einer Lightning-Demo Session eingestimmt, in der aktuelle Apps bzw. Websites vorgestellt wurden, die inspirierende Personalisierungsfunktionen anbieten.
Lightning Demos
Eine Methode mit der sich ein Team mit Produkten und Services für die Konzeptphase inspiriert. Wird in der Methodik „Design Sprint“ angewendet.
Ablauf – Jeder Teilnehmer recherchiert selbst 2-3 inspirierende Beispiele – Jeder Teilnehmer präsentiert die Beispiele – Die Kernideen werden auf Klebezetteln geschrieben und an ein Board angebracht
Am Ende hat das Team 10-20 Ideen zu dem Thema gesammelt. Es geht darum von allen Teilnehmern die besten persönlichen Ideen aufzunehmen und dabei nicht zu diskutieren.
Am Morgen des ersten 1. Tages stellten die Teilnehmer 6 Projektideen vor. Neben 5 technischen Vorschlägen aus dem Mobile-Umfeld hatten wir mit dem Design-Sprint-Projekt auch ein Methode aus dem UX-Umfeld am Start. So starteten wir nach dem Pitch mit 4 Teams in die Projekte.
Der Pitch – Nach den Vorstellungen wählten die Teilnehmer ihr jeweiliges Projekt
Team Mini Design Sprint – Solve Big Problem And Test New Ideas
Das Thema Personalisierung sind wir methodisch mit einem Mini Design-Sprint angegangen. Ein Design-Sprint ist Konzeptionsmethode für Produkte, die innerhalb von 5 Tagen mit dem Team durchgeführt wird. Da nur 2 Tage zur Verfügung standen, wurde das Format „kreativ“ komprimiert. Ziel der 2 Tage war das Kennenlernen der Methode und die Erstellung von interaktiven Prototypen für die Kundenapp unseres Partners. Bei diesem Non-Coding-Projekt stand also nicht die Programmierung, sondern die Methodik zur Generierung neuer Produktideen im Fokus.
Design Sprint
„The Design Sprint is a five-day process for solving problems and testing new ideas.“
Invented at Google by Jake Knapp, perfected with more than 150 startups at GV, then shared with the world in the bestselling book “Sprint – How To Solve Big Problems and Test New Ideas in Just Five Days”.
“On Monday, you make a map of the problem. On Tuesday, each individual sketches solutions. On Wednesday, you decide which sketches are strongest. On Thursday, you build a realistic prototype. And on Friday, you test that prototype with five target customers.”
In den 2 ziemlich durchgeplanten Tagen hat das Team im ersten Schritt in Experteninterviews die Challenges zum Thema Personalisierung zusammengetragen und priorisiert. Die Interviews wurden mit 2 Personen aus den Bereichen Business, Markting/Sales und Tech durchgeführt.
How we might … „Wie könnten wir persönlich Kunden ansprechen, ohne das es creepy wird“?
Es wurden ambitionierte 2 Jahresziele und mögliche Hindernisse auf dem Weg identifiziert. Auf dieser Basis wurden Lösungskontext und Fokusgebiet geschärft und das Team hat eine Lightning Demo Session durchgeführt. Anschließend hat jeder Teilnehmer eine eigene Produktidee ausgearbeitet und als Paper-Prototype in 3 Schritten visualisiert. Zwei Ideen wurden nach intensiven Diskussionen ausgewählt, um Flows auszuarbeiten und final interaktive Prototypen zu erstellen.
Mit den Ideen „Find your Style” und “Love me Tinder” ging das Team in die Abschlusspräsentation. Der Hackathon-Designsprint war damit abgeschlossen. Die Phase der Nutzer-Validierung möchte das UX-Team im Nachgang zusammen mit der Product-Ownerin angehen.
Die 8 Teilnehmer waren von der Methode und den Ergebnissen begeistert. Unser UX/UI-Lead Nicolai hat den Design-Sprint sehr gut vorbereitet und moderiert. Das Team bestehend aus Designern, Product Owner, Entwickler, QA, Scrum Master und Team-Manager hat viele Perspektiven in die Konzeptphase eingebracht und so für unseren Kunden einen wertvollen Input für die Produktentwicklung geben können.
Paper Prototypes
Team KRAS – Konferenz Raum Anzeige System
Mit der Projektidee sollte ein ganz praktisches Problem in unserem Office gelöst werden. Steht man vor einem unserer Meetingräume und möchte wissen ob oder ab wann dieser belegt ist, muss man erst eine Buchungsanfrage am Rechner durchführen, um an die Information zu gelangen. Da gehen schon mal ein paar Minuten ins Land. Das geht besser!
Die Informationen sollen mit einem kleinem Display an jedem Raum angezeigt werden. Darauf soll die aktuelle Tagesbelegung dargestellt werden.
Das Team hat sich für Angular als Frontendtechnologie entschieden. Die UI ist responsiv und kann auch auf kleinen eInk-Devices dargestellt werden. Neben der Darstellung der Rauminformationen hat das Team auch damit begonnen, eine Schnellbuchungsfunktion für den Raum zu implementieren. Die Web-UI wurde mit einer Android-App auf einem modifizierten Tolino eInk-Reader und auf einem Android-Tablet dargestellt. Aufgrund der deutlich langsameren Geschwindigkeit der eInk-Displays müsste die UI im nächsten Schritt weiter optimiert werden. Z. B. ist eine Alternative für das Scrolling durch Listen nötig.
Neben der Web-UI hat das Projektteam auch eine Arduino-basierte ePaper-Hardwarelösung mit Mikrokontroller evaluiert. Die Lösung ist äußert energiesparsam.
Die REST-API wurden über einen Node.js-Server realisiert, der auf einem Raspberry Pi läuft. Eine Herausforderung lag in der Anbindung des Thalia Exchange-Servers, der die Informationen zu den Räumen bereitstellt. Zusätzlich wurden Metadaten zu den Räumen wie z. B. vorhandene Meeting-Technik und Größe hinterlegt.
In den 2 Tagen konnte sich das Team gut in das umfangreiche Thema einarbeiten. Ein weiteres Learning war, dass für die Koordination der Subteams entsprechend Zeit eingeplant werden muss. Alle im Team waren hoch motiviert für ihre Bereiche Lösungen zu erarbeiten und diese mit den anderen zu integrieren. Die erarbeitete Lösung ist nahezu fertig, um sie mit einem ersten Meetingraum zu testen.
Team Flutter Touch – We want to Flutter you!
Mit dem Thema Cross-Plattform Entwicklung unter Anwendung von Google’s Flutter hat sich auch dieses Jahr ein Team beschäftigt. Flutter ist mittlerweile in Version 1.7 veröffentlich. Neben iOS und Android existiert auch ein Technology Preview für das Web. Seit Ende 2018 ist Flutter production-ready und die Flutter Community wächst kontinuierlich. Das Team hatte 2 Teilnehmer die bereits Projekterfahrung mit Flutter hatten.
Unter dem Topic „Feed-Configurator” hat das Team für die Kundenapp unseres Partners eine Individualisierungsfunktion geschaffen, um die Produktbereiche wie „Für dich ausgewählt“, „Kategorien“ oder „Marken“ in der Reihenfolge zu ändern. Mit dem „Tinder-Swipe für Produkte“ Feature kann der Kunde im Tinder-Stil Produkte durch Wischen nach links oder rechts als interessant bzw. uninteressant markieren. Die Daten könnten später in eine Recommendation-Engine überführt werden, um bessere Produktvorschläge zu machen. Präsentiert wurden die Funktionen im Web, auf iOS und auf Android.
Das Tinder-Feature hat das Team sogar auf einem Android-Wearable (Uhr) im Emulator gezeigt. Großartig!
Wearables – Wie können wir Wearables im Douglas Kontext einsetzen?
Das Team hat sich einen Usecase im Kontext Personalisierung überlegt. In diesem werden Produktempfehlungen als personalisierte Push-Notification auf dem Wearable dargestellt und sollen über Smart-Actions auf den Merkzettel oder in den Warenkorb gelegt werden können. In der Filiale könnte man sich auch vorstellen die Produkte direkt über einen Paymentdienst wie Google Pay zu bezahlen.
Entwickelt wurden die Prototypen auf iOS, Android und Tizen. Über ein Google Firebase-Setup sollten die Push Notifications auf die Geräte gesendet werden. Die Anwendungen liefen jeweils in den Emulatoren der Plattformen. Die Produktdetails wurden von den Partner-APIs abgerufen und auf den kleinen Displays dargestellt. Die Entwickler waren davon überrascht, wie schnell sie auf den Wearables entwickeln können.
Unser Fazit
Das Feedback der Teilnehmer und unseres Partners Douglas war äußerst positiv. Den Hackathon auf 2 Tage zu erweitern, gab den Teams mehr Zeit sich inhaltlich intensiver mit den Themen zu beschäftigten und ihre Präsentationen vorzubereiten. Die Bandbreite der Themen war technologisch und inhaltlich groß und brachte den Teilnehmern viele interessante Einblick in die Themen, mit denen wir uns vielleicht schon morgen beschäftigen werden.
Da auch Douglas-Mitarbeiter in Berlin dabei waren, konnte wir uns persönlich besser kennenlernen und austauschen. Die Projekte waren allesamt spannendend und wir haben unser Ziel erreicht mit dem Schwerpunkt Personalisierung einen direkten Mehrwert in Form von Protoytpen, Methodik und Inspiration für Produktideen zu schaffen.
Die Abschlussphase mit den Präsentationen und die Preisverleihung hat den Hackathon-Event gekonnt abgeschlossen. Wir freuen uns schon auf das nächstes Jahr!
Und noch ein paar weitere Inspirationen …
Team KRAS – 1. Preis
Team miniDesignSprint – 2. Preis
Möchtest du mehr über uns erfahren? Dann empfehle ich dir auch die folgenden Beiträge und Links:
Am Standort Berlin entwickeln wir für unseren B2B-Partner Douglas unter anderem die Kunden-App [2], [3]. Einhergehend mit dem Ausbau der App-Entwicklungsaktivitäten haben wir in den letzten Monaten den CI-Ansatz überarbeitet. Ein zusätzliches Team sollte am selben Produkt – der KundenApp – mitarbeiten und die App sollte öfter veröffentlicht werden. Mit Methoden und Tools aus dem Bereich Continous Integration wollten wir dafür sorgen weiter zuverlässig und mit hoher Qualität zu liefern. Und das natürlich automatisiert. Neben der Technik geht es auch um die Teams. Wie sind sie vorgegangen und welche Hürden haben sie genommen.
Komplexität und Feedback
Je mehr Personen gleichzeitig an einem Produkt entwickeln, desto größer wird die Wahrscheinlichkeit, dass unbeabsichtigte Seiteneffekte auftreten. Gleichzeitig steigt der Umfang der App, da wir konstant neue Funktionen hinzufügen und bestehende Funktion ändern. Um die Komplexität weiter zu beherrschen, ist schnelles Feedback zu Änderungen ein entscheidender Faktor, um Probleme schnell zu korrigieren. Wie wäre es, automatisiert ein Feedback nach jedem Commit zu bekommen und darauf nur kurze Zeit warten zu müssen? Genau hier setzten wir an.
Schnelles Feedback erhalten wir durch den Einsatz von Feature-Toggles und durch die Ausführung von automatischen Tests im CI-Prozess.
Feature Toogles
Feature Toogles ermöglichen es uns Codeänderungen aller Entwickler kontinuierlich in einen gemeinsamen Integration-Branch zusammenzuführen. Und das auch, wenn Features noch nicht fertig bzw. für den Kunden nicht sichtbar sein sollen. In der Vergangenheit haben wir solche Features für mehrere Tage, manchmal Wochen, in separaten Branches entwickelt und erst am Ende der Entwicklung in den Integration-Branch gemergt. Das Feedback kam entsprechend spät. Traten Probleme auf, war es durch die Vielzahl der Änderungen mitunter schwer festzustellen, welche konkrete Änderung zum Bruch geführt hat. Die Integration hatte das Potential unsere Zeitplanung empfindlich zu stören. Diese Bing-Bang-Szenarien sollen durch Toggles und kontinuierliche Integration abgefedert werden.
Toggles und Diskussionen
Der Einsatz der Feature-Toggles wurde im Team intensiv diskutiert, denn die Einführung erhöht erstmal die Komplexität – und liebgewonnen Pfade, wie die isolierte Arbeit im Feature-Branch, standen auf einmal auf dem Prüfstand. Es gab diverse Pros und Cons. Auch musste ein gemeinsames Verständnis beim Thema Toggle-Mechanik erarbeitet werden. In Bezug auf Dynamik und Langlebigkeit der Toggles gab es unterschiedliche Auffassungen, da viele schon mal irgendetwas mit Toggels gemacht hatten.
Wir haben uns am Ende auf die Nutzung von Feature-Toggels zur Entwicklungszeit – auch Release-Toggles genannt – geeinigt. Sie werden für den Zeitraum weniger Tage/Wochen genutzt. Ist das Feature fertig entwickelt, wird der Toggle aus dem Code komplett entfernt. Der Artikel auf martinfowler.com [1] sei dem interessierten Leser an der Stelle empfohlen.
2 bis 3 Feature-Toggle sind im Durchschnitt parallel im Einsatz. In unserem Jenkins haben wir durch einen manuellen Schritt in der Build-Pipeline die Möglichkeit geschaffen, einen einzelnen Toggle zu aktivieren und somit App-Artefakte für Features (apk, ipa) für das Testing zu bauen. Ist das Feature komplett entwickelt, wird der Toggle aus dem Code entfernt. Mit dem nächsten App-Release ist das Feature dann für den Kunden sichtbar.
Was ist ein Feature Toggle?
Ein Feature Toggle ist eine Progammiertechnik, die es erlaubt ein Feature oder eine Funktion vor Kunde ein- bzw. auszuschalten. Also die Sichtbarkeit zu ändern. Entwicklungsteams aktivieren Features beispielsweise um noch nicht fertige Funktionen integrieren und testen können. Ist ein Feature fertig, kann es ohne großen zusätzlichen Merge-Aufwand veröffentlicht werden, da die Arbeit in separaten Branches entfällt. Feature Toggles können auch dafür genutzt werden, die Sichtbarkeit von Funktionen zur Laufzeit der Anwendung zu ändern. Z.B. im Rahmen von A/B Tests oder wenn die Sichtbarkeit zu einer bestimmten Zeit geändert werden soll.
Toogles im Code
iOS
Unter iOS wird ein Feature in der App über eine Environment-Variable in der Launch-Konfiguration aktiviert (z.B.: USE_NATIVE_PRODUCT_LIST = 1). Im Code wird dann an relevanten Stellen über eine Abfrage entschieden, ob bestimmte Codestellen zur Ausführung kommen oder nicht.
if toggleRouter.isNativeProductListEnabled() {
// Feature Code
}
Android
Es gibt ein Interface, in dem alle Toggles als Methoden definiert werden. Diese Methoden werden mit Java-Annotations annotiert und geben immer ein Boolean zurück – TRUE für Feature aktiv, FALSE für nicht aktiv.
@ReleaseToggle(BuildConfig.FEATURE_PRODUCT_LIST)
fun isProductListEnabled(): Boolean
Eine eigens dafür entwickelte Library mit einem Annotation-Prozessor wird während der Build-Phase ausgeführt: Dieser schaut in einer Konfigurations-Datei (json) nach, ob das jeweilige Feature getoggelt werden soll. Wenn das Feature eingeschaltet werden soll, muss der String, der sich in der Annotation befindet, hier eingetragen werden.
[
"FEATURE_PRODUCT_LIST"
]
Der Prozessor baut dann jeweils die Implementation für das Interface zusammen. In diesem Fall würde die implementierte Methode TRUE zurück liefern. Wäre der String FEATURE_PRODUCT_LIST nicht in der Datei, wäre es FALSE.
So kann man auf jedem lokalen Rechner die Features beliebig ein- und ausschalten. Auf dem Jenkins kann man das genauso machen, hier editieren wir nicht manuell die Datei sondern sagen ihm über das Blue Ocean Plugin, welches Feature getoggelt werden soll.
Und die jeweiligen Code-Stellen togglen wir, in dem wir die Interface-Implementation prüfen:
if (ReleaseToggleConfiguration_Impl().isProductListEnabled()) {
// Mach was mit der Product list
}
Ein gemeinsames Traffic Light für Build und Test
Eine weitere zentrale Komponente im CI-Prozess stellt die Testautomatisierung dar. Das Feedback, dass Build und Test erfolgreich nach einem Commit auf Integration durchgelaufen sind, wird durch eine Ampel visualisiert. Diese ist für jedem im Team sichtbar. Ist sie rot, ist das gesamte Team angehalten den Grund zu ermitteln und die Ampel wieder auf „grün zu bekommen“. Also Fehler zu korrigieren, Tests oder die Automatisierung anzupassen.
CI-Build-Status für Android und iOS
Die Tests sind eine Kombination aus Unit-Tests und End-2-End-Tests (Akzeptanztests). Die End-2-End-Tests laufen auf echten Geräten bzw. Simulatoren im Zusammenspiel mit dem Backend.
Continous Integration Process
Unser CI Prozess sieht wie folgt aus:
Nach dem Approval der Codeänderung in Gitlab und Integration in den Integrations-Branch baut der Jenkins das App-Artefakt, führt die Unittests aus und startet die End-2-End Tests. Das kombinierte Ergebnis aus Build/Unitests und End-2-End Test wird auf der Ampel dargestellt.
Für den Test eines Features, dass sich noch in der Entwicklung befindet, wird ein Feature-Toggle manuell im Jenkins aktiviert, die App gebaut und die Unittests ausgeführt. Die End-2-End Tests werden zum jetzigen Zeitpunkt noch nicht ausgeführt. Zum einen müssten die Tests für das Feature bereits angepasst und erweitert sein. Das ist noch nicht der Fall. Ein weiterer Grund sind die noch fehlenden Ressourcen in Form von Hardware und Testgeräten. Ein nächster Schritt.
Learnings zu Tools, Integrationslevel und Verantwortung
Auf drei Learnings möchte ich an der Stelle speziell eingehen.
Der Leser soll dazu wissen, dass unsere Entwicklungsteams Cross-funktional aufgebaut sind. Ein Entwicklungs-Team besteht aus iOS-Entwicklern, Android-Entwicklern, Backend-Entwicklern und einem Quality Engineer. Die Backend-Entwickler sitzen an einem anderen Standort und sind wie wir Dienstleister für den B2B-Partner. Folgende Tests führen wir zur Zeit durch:
Testtypen
Beim Tooling ging es vor allem um die Wahl des Testautomatisierungstools. Da die QA in der Vergangenheit auf Appium gesetzt hat, wollten wir die Technik auch für unsere CI-Tests im gesamtem Team nutzen (Dev+QA). Bisher wurden die Appium Test ausschließlich von der QA geschrieben und waren nicht in einem gemeinsamen CI-Prozess zusammen mit dem Build integriert. Es stellte sich heraus das die Akzeptanz des Tools für iOS unter den Entwicklern sehr gering war. Stabilität, Funktionsumfang, Integrierbarkeit und Ausführungsgeschwindigkeit überzeugten nicht. Unsere Teams haben sich daher entschieden, für iOS die End-2-End Tests auf Basis von XCUITest neu zu schreiben. Für den Android Bereich setzen wir vorerst weiter auf Appium.
Ein weiteres Learning gab es beim Integrationslevel. Unsere End-2-End Tests weisen ein hohes Integrationslevel auf: die App wird im Zusammenspiel mit dem Backend getestet. Fehler im Backend oder eine schlechte Verbindungsqualität können dazu führen, dass Tests fehlschlagen, obwohl die App „korrekt“ funktioniert. Die Ampel zeigt rot, obwohl „mit der App alles in Ordnung ist“. Flaky Tests bzw. instabile Tests senken die Aussagekraft der Ampel deutlich und führen dazu, dass die Teams einer roten Ampel weniger Aufmerksamkeit schenken. Neben dem End-2-End Test planen wir daher einen zusätzlichen Testtyp einzuführen, der vom Integrationslevel zwischen Unittest und End-2-End Test liegt. Ziel ist es die App ohne Backend zusätzlich zu verifizieren. Dafür sollen Backend-Responses „gemockt“ und die Tests auf der UI-Ebene durchgeführt werden. Die Test sollen eine Ergänzung zu den End-2-End Tests werden.
Beim Thema Verantwortung gehen wir mit dem CI-Ansatz ebenfalls neue Wege. Das Ergebnis aus Build + Test in einem gemeinsamen Ampelstatus zu visualisieren und damit jeden im Entwicklungs-Team zu aktivieren, Probleme im Test oder Build zu analysieren, erfordert, dass sich Entwickler mehr mit dem Thema Testing und sich die QA mehr mit der Automatisierung auseinandersetzt. Dieser Veränderungsprozess benötigt Zeit und den Willen aller Beteiligten sich zu verändern. In unserem Produktteams ist diese Veränderung explizit gewünscht und alle im Team sind angehalten für den Prozess Verantwortung zu übernehmen und ihn aktiv weiterzuentwickeln.
Ausblick
Im Bereich Testing steht der Ausbau der Testautomatisierung für die End-2-End Tests und die Einführung der zusätzlichen Test-Verifikationsstufe für die Android-App mit Espresso als UI-Testing Tool an.
Um die Qualität zu steigern, möchten wir automatisiert statische Codeanalysen durchführen und Metriken wie beispielsweise die technische Schuld ermitteln.
Scrum Teams verteilen sich zusehends mehr über verschiedene Standorte und was für uns in Scrum Meetings wie Dailys, Estimating & Refinement und Reviews noch ein relativ kleines Problem darstellt, ist für unsere Retrospektiven eine wirkliche Herausforderung. Als Scrum Master ist mir für eine Retrospektive das Gefühl von Vertrauen und volle Aufmerksamkeit sehr wichtig. Das erkenne ich am besten anhand der Körpersprache der Kollegen im Raum. Ich kann ihnen bei Fragen ins Gesicht sehen und es gibt keine unangenehmen Unterbrechungen im Dialog, weil durch technische Verbindungsabbrüche die Datenübertragung vom Mund zum Gehör gestört wurde. All das ist mir sehr wichtig bei einer Retrospektive und dennoch haben wir einen Weg gefunden, sie über Videokonferenzen und weitere Werkzeugen nicht nur zu veranstalten, sondern auch erfolgreich für alle Beteiligten durchzuführen.
Wie ist das Möglich?
Einer der wichtigsten Punkte ist, dass alle Beteiligten sich schon mal in Persona begegnet sind. Sie sind dann füreinander mehr als nur eine Stimme aus dem Kasten oder ein Torso auf dem Bildschirm. Es ist eine Persönlichkeit mit einem Privatleben, über das ich die ein oder andere Geschichte gehört habe. Es muss also dafür gesorgt werden, dass sich das Team mindestens einmal, besser noch häufiger im Jahr trifft und auch neben der Arbeit miteinander interagiert.
Die Qualität der Videokonferenz (VK) Software ist entscheidend für alle Meetings eines verteilten Scrum Teams. Es bedarf sehr guter Mikrofone und Lautsprecher. Das Mikrofon muss Nebengeräusche ausfiltern können. Die Lautsprecher sind auf die gängigen Frequenzgänge unser Sprache mit einem Equalizer angepasst worden. Das Video sollte jedes Mitglied (einzeln) aufnehmen. Die Einrichtung der Konferenz sollte nahezu ohne Aufwand vonstattengehen. Als ideales Setting würde ich mir alle Teilnehmer mit derselben Ausstattung wünschen. Eigener Laptop, eigenes Mikrofon und Kopfhörer sowie eine eigene Kamera. Absolute Gleichberechtigung.
Das ist die grundlegende Intention. Tatsächlich kämpfen wir bei jedem Meeting mit mindestens zehn Minuten der unterschiedlichsten Unwegsamkeiten zu einer stabilen VK. Die Komponenten Internetverbindung, Mikrofon, Telefon und Kamera können eine beliebig komplexe Matrix von Fehlerzuständen darstellen.
Unser Fazit war: 15 Minuten Vorbereitung des Meeting vor das Meeting setzen! Es lohnt sich.
Was wir immer noch falsch machen
Wir gruppieren Menschen in einem Konferenzraum vor ein Mikrofon, ein Lautsprecher und eine Kamera und lassen sie mit den “Einzelkämpfern” interagieren. Sie fangen an untereinander zu tuscheln und ein Teil der Gruppe ist raus. Der Scrum Master als Moderator bekommt es unter Umständen gar nicht mit. Aus irgendwelchen kosmischen Gründen beginnen immer zwei Personen gleichzeitig einen Satz, wenn man in einer VK ist. Beide Seiten hören sich nicht. Als Moderator ist man bemüht, eine weitere wichtige Regel durchzusetzen. Wer nichts zu sagen hat, schaltet sein Mikrofon aus. Pausen lassen und deutlich auf das Ende eines Beitrags hinweisen. Nicht umsonst gibt es im Sprechfunk “over and out” / “Komme und aus”. So prägnant muss das nicht sein, aber man sollte geduldig bleiben, auch wenn die Diskussion gerade hitzig wird.
Das sind nur die Maßnahmen, die notwendig sind, um die Kommunikation zwischen allen Beteiligten zu gewährleisten, aber wir möchten eine Retrospektive durchführen, deren Inhalte durchaus emotional und vertraulich sein können. Ist das überhaupt möglich?
Wir haben eine kostenpflichtige Software namens Retrium ausprobiert und recht gute Erfahrungen damit gemacht. Retrium bietet eine Reihe von vordefinierten Retrospektive an, die sehr gut Schritt für Schritt erklärt und geführt sind. Dazu gehören “4 L’s”, “Start, Stop, Continue”, “Mad, Sad, Glad”, “What went well, what didn’t go well” und “Lean Coffee”. Zudem kann man eigene Retrospektiven bauen, solange sie aus Spalten mit der Möglichkeit zum Kommentare schreiben besteht. Des Weiteren gibt es Team Radars zu den Themen Entwicklung, Arbeitsplatz und Scrum, die auch gerne von den Team-Mitgliedern angenommen werden.
Das Vorgehen ist sehr ähnlich. Themen sammeln, Gruppieren, Priorität abstimmen, Besprechung und Action Items beschließen bis alle Themen abgearbeitet sind. Nur die Fragestellung ändert sich marginal. Methoden zum Beginnen und zum Abschließen des Meetings fehlt in diesem Kontext. Wer mehr möchte, muss kreativ werden.
Wir haben nach digitalen Whiteboards gesucht, auf denen man auch komplexere Fragestellungen und Interaktionen darstellen kann. Die gibt es reichlich auch unentgeltlich. Die Option Post-its zu setzen, ist das beliebteste Akzeptanz Kriterium für solche Boards. Es hat sich als nützlich erwiesen, den Teilnehmern den Zoom zu verbieten. Ansonsten bekommt man viele unterschiedlich große Post-its mit dem Gefühl das Größte ist am lautesten und wichtigste. Also Zoom auf 100% und Finger weg von den +/- Tasten.
Zum Abschluss noch einige Erfahrungen zur Interaktion der Teilnehmer. Sie sind wahrscheinlich abgelenkt. Als Moderator ruft man die Teilnehmer kontinuierlich auf, ihren Beitrag zu leisten. Am besten konkret mit Namen und ggf. mit der Frage oder dem Arbeitsauftrag. Bei Antworten oder Beiträgen wiederholt man das Gesagte und fragt, ob ihr es richtig verstanden wurde. Das ist als Aktives Zuhören bekannt. Die Verständnisnachfrage ist legitim und entschleunigt den Prozess merklich. Es mag merkwürdig klingen, aber je langsamer man in dieser Situation wird, um so mehr wird man schaffen.
Letztendlich wird sich das alles einspielen und alle Beteiligten kennen die Defizite und können damit umgehen. Es wird zu Dialogen und sogar Diskussionen kommen. Man kann sie, wie am Telefon auch, ohne Körpersprache führen und etwas Positives herausholen. Wenn man die oben genannten Regeln zur Gleichberechtigung einhält, vermutlich noch eher, als mit vielen unterschiedlichen Konfigurationen. Die Whiteboards können für viel Erheiterung sorgen, wenn zwei Personen versuchen, dasselbe Post-its zu verschieben. Nach so einer Retrospektive hat man auch körperlich das Gefühl, etwas geschafft zu haben. Wir haben inzwischen einige durchgeführt und immer vernünftige Action Items beschließen können. Es ist möglich, aber man muss sich mit vielen Faktoren auseinandersetzen, die bei einer “analogen” Retro keine Rolle spielen. Plant mehr Zeit ein und habt eine geringe Erwartung am Anfang. Nehmt euch nicht zuviel vor und seid auch mit bescheidenen Ergebnissen zufrieden. Es wird mit der Zeit besser werden. Versprochen.
Musencast V: Refinement
Die aktuelle Folge unseres Podcast beschäftigt sich mit dem Refinement/Grooming/Estimating/…-Meeting.
Viel Spaß beim Hören! Wir freuen uns wieder über Feedback oder auch Fragen! Heute auch ganz exklusiv hier zu finden: https://open.spotify.com/show/27mJcNKcPmR739qu5jCeUp?si=1HK8ZcXRT32MmWbh2qvpAw
Patrick & Matthias
Wofür eine Supervision?
Gruppe von Figuren mit Puzzleteilen. Supervisor mit einem zusammengesetzten Puzzle aus den Teilen.
Wofür eine Supervision, wenn wir doch einen Scrum Master/Agile Coach haben? Die Frage stellen sich vermutlich einige, die das erste Mal hören, dass ein Team einen Supervisor eingeladen hat, etwas zu tun, was in Berufen im sozialen oder karitativen Umfeld Gang und Gäbe ist. Solche Menschen mit hohen emotionalen und psychischen Druck werden geradezu verpflichtend angeleitet, in einer Supervision über ihre Arbeit und das Verhältnis zu ihren Kollegen und Klienten zu reden.
Doch was hat das mit einem Softwareentwicklungsteam zu tun? Die Antwort liegt in den Rollen, in denen wir unsere Arbeit erledigen. Hier kann es zu Spannungen zwischen der Erwartungshaltung und den Bedürfnissen kommen. Jeder Mensch hat unterschiedliche Erfahrungen und damit Wahrnehmungen. Wie intellektualisieren unser Beobachtungen und damit sind sie immer einzigartig. Wenn darüber nicht gesprochen wird und ein Abgleich erfolgt, kann es zu Missverständnissen und Konflikten kommen.
Doch die Frage bleibt. Dafür haben wir doch den Scrum Master. Das ist zum Teil auch richtig und ein Scrum Master kann neben den Fragen zum Prozess, oft auch Fragen zur besseren Zusammenarbeit mit den Kollegen beantworten. Aber so viel Mühe sich ein Scrum Master auch gibt, unabhängig oder sogar allparteilich zu sein, so bleibt er doch immer ein Mitglied des Scrum-Teams. Absolute Objektivität ist damit nicht mehr erreichbar. Zudem wird von dem Scrum Master quasi erwartet, dass eine Lösung für ein Problem in ein bis zwei Stunden, während der Retrospektive gefunden wird.
Dafür ist die doch da, oder? Wie oft hört man den Satz:”Wir reden doch jedes Mal über dasselbe.” Oft werden dann nur die Symptome behandelt, aber nicht das chronische Problem. Wie nah kann man in einer Stunde dem Kern des Problems kommen? Kann ein Scrum Master ohne Ausbildung in Psychologie das überhaupt leisten? Selbst Mediatoren arbeiten nur an der Oberfläche des Problems im hier und jetzt für die Zukunft mit einer Lösung. Bräuchte das Team nicht eher ein Psychotherapie oder sogar Spuren eine Psychoanalyse? Ein Supervisor ist in der Regel auch ein Psychologe mit Erfahrungen in genau diesen beiden Bereichen. Sie oder er nimmt sich die Zeit, die es braucht. Sie stellen dem Team eine wichtige Frage:
“Was glauben Sie, wird nach der Supervision besser sein als zuvor?”
Es werden die Themen gesammelt, die das Team und die Teammitglieder bewegen. Die Themen werden wertfrei umgeformt und allein dafür braucht es manchmal einen Außenstehenden, der nicht selbst in den Konflikt involviert ist. Danach kann man Thema für Thema zum Kern des Konfliktes kommen und hoffentlich, nach einer emotionalen oder sachlichen Diskussion, eine gemeinsame Lösung finden.
Nicht jedes Team braucht einen Supervisor. Manche schaffen es, offen mit ihren Konflikten umzugehen. Sie können über ihre Unterschiede reden und sich verstehen lernen. Sie können über ihre Erwartungen sprechen und sie vernünftig anpassen. Sie schaffen es auch aus emotional stressigen Situationen herauszukommen und sich weiterhin in die Augen sehen zu können.
Andere bitten um Hilfe, wenn sie Hilfe brauchen und das ist auch gut und richtig so. Manche bitten um die Hilfe eines Supervisors, wenn die Konflikte im Team zu lange gereift sind, als dass man sie in 1-2 Stunden Retrospektive aufbrechen könnte.
Zu dieser Einschätzung sind wir auch beim Team RED gekommen, das Monate, wenn nicht Jahrelang ohne einen Scrum Master zu einem sehr guten Scrum Team gewachsen ist. Nur hatten sie dabei niemanden, der so objektiv wie möglich und manchmal notwendig, die wahren Konflikte angesprochen hat. Dennoch sind wir zu der Erkenntnis gekommen die Hilfe anzufordern, die auch ein Scrum Master dem Team nicht mehr geben konnte. Damit sind wir die ersten* bei Thalia, die mit einem Supervisor zusammenarbeiten. Unser Ziel ist es, die Zusammenarbeit durch ein besseres Verständnis unserer Persönlichkeiten zu verbessern. Der Weg dahin wird nicht immer ohne schmerzvolle Erkenntnisse ablaufen und wir stehen noch relativ am Anfang. Die Veränderungen sind noch klein, aber von Bedeutung. Wir gehen von ungefähr acht Besuchen des Supervisors alle sechs Wochen aus und werden sehen, wie wir uns verändern. Wir werden kaum unsere Persönlichkeiten verändern, aber unser Verhalten können wir noch beeinflussen.
*soweit dem Autor bekannt ist
Musencast IV: Planning
Die aktuelle Folge unseres Podcast beschäftigt sich mit dem Planning-Meeting in Scrum.
Viel Spaß beim Hören!
Wir freuen uns wieder über Feedback oder auch Fragen! Heute auch ganz exklusiv hier zu finden: https://open.spotify.com/episode/7kpGryFGJ9aHvxsXSwl7QT?si=LHd4iIEjSa-jUmltv2B_LA
Patrick & Matthias
Musencast III: Daily Stand-up
Die dritte Folge unseres Podcast beschäftigt sich mit dem „Daily Stand-up“. Viel Spaß beim Hören!
Wie immer würden wir uns über Euer Feedback freuen. Solange es hier mit Kommentaren nicht funktioniert gerne auch über die Netzwerke!
