von Diana Kruse

Wir Quality Specialists schauen nicht nur über den teameigenen Tellerrand, indem wir uns in bereichsweiten Formaten wie QS-OpenSpace, QS-Conventions und Fokusgruppen rund um das Thema Qualität austauschen. Wir strecken unsere Fühler auch konzernweit und über den Konzern hinaus aus.

In diesem Beitrag möchte ich kurz über die QConf sprechen, der jährlichen konzernweiten Konferenz für alle Software-Qualitäts-Interessierten der otto group.

Seit dem letzten Jahr haben sich die einzelnen IT-Bereiche stark weiterentwickelt. Konzernweit spiegelt sich in etwa das wider, was ich auch am Markt verfolge: Es gibt Bereiche, die noch am Anfang stehen, was agile Software(Qualitäts)Prozesse angeht. Andere, wie wir bei otto.de, leben und verändern diese schon seit einigen Jahren.

Die QConf in Zahlen

750
Feedbackzettel
70
aktive Teilnehmer
17
Stunden Softwarequalität
16
Speaker / Workshopleader
4
Sponsoren
4
Orgas
1
riesiger Raum
Jeder Bereich steht somit vor anderen Herausforderungen und doch macht uns ein Gedanke alle gleich:

„Wie können wir unterstützen, dass qualitativ hochwertige Software an unsere Kunde geliefert wird?“

Von Natalie Volk, Finn Lorbeer, Diana Kruse, und Torsten Mangner

Bei otto.de gibt es in jedem Cross-Functional-Team mindestens eine Testerin / Testmanagerin / QA / QSlerin… wie auch immer man die Rolle der Person bezeichnet, die Bewusstsein für Qualität schaffen soll.

Bisher dominierte die Bezeichung „Testmanagerin“ – ein sehr hölzerner, bürokratisch klingender Titel. Dieser sollte deutlich machen, dass die Rolle mehr tut, als nur Tests durchzuführen: Sie managed Tests! Mittlerweile ist auch das managen von Tests nur noch ein kleiner Teil des Mehrwerts, den wir im Team erbringen.

A Completely Biased Summary of the Assets of Microservice Architectures

by @GuidoSteinacker

When we started ‚Lhotse‘, the project to replace the old, monolithic e-commerce platform of otto.de a few years ago, we chose self-contained systems (SCS) to implement the new shop: Instead of developing a single big monolithic application, we chose to vertically decompose the system by business domains (’search‘, ’navigation‘, ‚order‘, …) into several mostly loosely coupled applications. Each application having it’s own UI, database, redundant data and so on. If you are more interested in the ‚how‘ instead of the ‚why‘, please have a look into an earlier article on monoliths and microservices.

Lately, some of these SCS turned out to be still too large, so we decomposed them by extracting several microservices. Because we are already running a distributed system, cutting applications into smaller pieces is now a rather easy exercise.  One of the reasons, why I agree with Stephan Tilkov that you should not start with a monolith, when your goal is a microservices architecture.

This article is not about the pros and cons of microservice architectures. This article is mostly about the pros. Not because they do not have downsides, but because I’m biased and completely convinced that microservices are a great idea.

LHOTSE is the internal code name for our project to re-develop www.otto.de: in-house, based on open source software and using agile methodologies such as Scrum and XP. LHOTSE went live on 24th October 2013 – three months before schedule. Although it took us roughly two years to develop, with a team of more than 100 experts, getting LHOTSE live was practically a „non-event“. So, why did everything work out so well?