queo hat in der Vergangenheit intensiv an zwei Projekten zur internen Weiterentwicklung gearbeitet. Dazu haben wir Dr. Christian Wende, Geschäftsführer von DevBoost, ins Boot geholt. Die Zusammenarbeit begann mit einer Lösung zur Testautomatisierung, die gemeinsam mit Ralf Michael, Head of PHP bei queo, erarbeitet wurde. Im weiteren Verlauf widmete sich Christian mit Matthes Winkler, Head of Technical Consulting, dem Thema Anforderungsanalyse. Wie die Zusammenarbeit ablief und was queo bei diesen Themen wichtig ist, beantworten die drei Beteiligten im Interview.

Was tut DevBoost für seine Kunden?

Christian: Wir treten mit DevBoost am Markt in zwei Rollen auf. Einmal sind wir Softwareentwickler, vorrangig in den Branchen Produktion, Logistik, Energiewirtschaft und zunehmend auch im Bereich Automotive. Wir wollen innovative Businessmodelle mit Software ermöglichen. Mit unseren Projekten betreten wir Pfade, die vorher noch nicht begangen wurden. Uns reizt dabei die „Enabling Technology“. Die zweite Rolle, in der queo uns vor allem kennengelernt hat, ist die des Beraters. Wir wollen unseren Anspruch an Qualität und Effizienz in der Softwareentwicklung mit anderen teilen und unsere Kollegen in anderen Firmen dazu befähigen, ihren Job mit dem gleichen Anspruch zu erfüllen. Die Motivation dahinter ergibt sich aus der großen Verantwortung, die wir als Entwickler haben: wir gestalten wie unsere Zukunft aussehen wird. Das klingt zuerst dramatisch, aber wenn man drüber nachdenkt, erkannt man, dass Software mittlerweile fast alle Bereiche unseres Lebens durchdringt. Der Schlüssel ist zu verstehen, dass Softwareentwicklung ein Prozess des ständigen Fehlers ist und das tolle Ergebnis niemals der erste Schuss war. Wenn man das begriffen hat, kann man an die Arbeit ganz anders herantreten. Die Rolle als Softwareentwickler ist meiner Meinung nach die leichtere, aber die Beraterrolle gibt uns den größeren Hebel.

Du hast von Anspruch gesprochen, wie definiert ihr den für euch?

Christian: Was ich als großes Manko sehe ist, dass auch in der Softwareentwicklung betriebswirtschaftliche Themen die Oberhand gewinnen. Und dass kurzfristiges Denken, Shareholder-Denken und Denken in Quartalen, Entscheidungen beeinflusst. DevBoost hat zwei Geschäftsführer, die selber Softwareentwickler und -Architekten sind und aus dieser Brille heraus Entscheidungen treffen. Ich bin der festen Überzeugung, dass Qualität und Effizienz nicht in unterschiedliche Richtungen zeigen, sondern dass sie einander bestärken. Einerseits sind wir Softwareentwickler und haben mit den gleichen Problemen zu kämpfen, wie alle unsere Kollegen. Auf der anderen Seite haben wir den Beraterfokus und können beide Themen miteinander verbinden und in eine Waagschale werfen. Dadurch können wir auf Augenhöhe arbeiten.

Wie ist der Kontakt von queo und DevBoost zustande gekommen? Welche Themen haben uns beschäftigt?

Ralf: Mein Kontakt kam über Dirk, unseren Director Technology, zustande. Aber ursprünglich hat die Geschäftsleitung von queo mit DevBoost Kontaktpunkte über PAUL Consultants und aus Unizeiten.

Christian: Wir beobachten die Arbeit des Anderen mit sehr viel Wertschätzung und wollen gerne das Beste voneinander lernen. Ihr unterstützt uns beispielsweise in der SEO-Optimierung unserer Webseite, da haben wir euch als Experten ins Boot geholt und so war es sicher auch andersherum.

Matthes: Das erste große Projekt an dem wir zusammengearbeitet haben, war das Thema Testautomatisierung. Wir wollten schauen, wie wir die Abnahmetests bei queo am besten automatisieren können. Wir sind dann in einem zweiten Projekt noch ein ganzes Stück weitergegangen in Richtung Anforderungsanalyse.

Christian: Wenn man an einem pragmatischen Thema arbeitet, stellt man häufig fest was drum herum noch optimiert werden sollte, damit man eine technische Lösung überhaupt einsetzen kann. Deshalb kam es nach dem ersten Projekt zu dem zweiten Thema: der Anforderungsanalyse.

Wie sieht die Zusammenarbeit dann konkret aus? Christian, du kennst queo ja nicht im Detail. Beobachtest du zunächst unsere Arbeitsweise, oder wie gehst du vor?

Christian: Für das Thema Testautomatisierung mit Ralf habe ich eine technische Lösung mitgebracht, die wir uns dann gemeinsam angeschaut haben. Wenn ich im Beratermodus unterwegs bin, bin ich erstmal nur ein externer Trigger: sich die Herausforderungen anzuschauen und sich ihnen zu stellen. Ich habe vielleicht schon eine Lösungsidee im Kopf, aber letztendlich habe ich in der Beraterrolle die Aufgabe Zeit und Raum einzuräumen, zu moderieren und die „doofen Fragen“ zu stellen. Ich bin kein Beobachter der ein Review macht und sich ein Urteil bildet. Ich schaffe Platz für Diskussionen, helfe eine Lösung zu finden und ermögliche so Veränderung. Deshalb interessiert mich besonders was es auf lange Sicht bei euch bewirkt hat.

Matthes: Beim Thema Anforderungsanalyse haben wir zuerst den gesamten Prozess aufgenommen der bei uns vor der Entwicklung steht.

Christian: In den Workshops ging es vor allem darum, wie Software beschrieben, entwickelt und getestet wird. Bei queo hatten wir in den Workshops einen guten Querschnitt durchs Unternehmen: Softwarearchitekt, Projektleiter, Managementebene. So konnten wir die relevanten Punkte besprechen und alle wichtigen Instanzen abholen.

Matthes: Mit den Workshopteilnehmern haben wir versucht die verschiedenen Welten, in denen queo unterwegs ist, zusammenzuführen. Webseiten und Portale auf der einen Seite und Individualsoftwareentwicklung auf der anderen Seite. Uns war natürlich schon vorher klar, dass die Anforderungen sich durchaus unterscheiden. Aber queo ist in diesem Spannungsfeld tätig und deshalb haben wir uns darauf fokussiert.

Ralf, wie kam das initiale Thema Testautomatisierung zustande?

Ralf: Wir wussten, dass es noch andere Wege gibt als die die wir bisher gegangen sind. Vor allem die Aspekte Akzeptanz- und Abnahmekriterien haben für uns eine große Rolle gespielt. Wir haben zunächst angefangen uns in dem Thema stärker auszuprobieren. Aber dafür war die Zeit zu knapp und uns fehlte auch ein bisschen das Ziel auf unserer Suche. Es war uns wichtig jemand Externes zu holen, der erfahren ist und Anreize setzt. Sonst hätten wir alles selber evaluieren und lernen müssen und dazu fehlt im Projektalltag einfach die Zeit. Jemand der Raum und Zeit dafür schafft, dass wir uns dem Thema in Ruhe widmen und die Aufmerksamkeit geben die wir dem Thema geben wollten. Die Arbeit an dem Projekt Testautomatisierung dauerte zehn Tage.

Christian: Der zweite Workshop im Bereich Anforderungen dauerte ebenfalls zehn Tage. Das ist ein guter Zeitraum um Dinge anzustoßen und die ersten Schritte gemeinsam zu gehen.

Matthes, was hat sich queo von der Zusammenarbeit im Bereich Anforderungsaufnahme erhofft?

Matthes: Input von jemandem, der dieselben Herausforderungen bewältigt. Mir ist schnell klar geworden, dass sich kein Vorgehen 1:1 übertragen lässt. Weil die Voraussetzungen und Arbeitsweisen von Unternehmen zu Unternehmen verschieden sind. Man kann nicht einfach einen fremden Prozess über die eigenen Prozesse stülpen. Deshalb sind wir schnell in den Modus übergegangen, dass Christian sich verschiedene Punkte angeschaut und Fragen gestellt hat. Warum haben wir das so gemacht? Was ist dabei unser Ziel gewesen? Wir haben offen und ehrlich miteinander gesprochen und dann einen Baukasten entwickelt: Wie sollen Anforderungsbeschreibungen zukünftig aussehen? Für uns war wichtig nicht zu sehr ins Detail abzuschweifen, sondern generisch zu arbeiten. Es ist keine eierlegende Wollmilchsau entstanden, aber es wurden verschiedene Prozesse angestoßen.

Christian: Softwareentwicklung bleibt der von mir beschriebene Prozess von Fehlern. Man darf nicht versuchen auf ein wasserdichtes, allgemeingültiges Konzept hinzuarbeiten.

Ralf: Für mich ist an der Stelle besonders die Erkenntnis des Problems wichtig. Erkenntnis der Fehlerstellen und das Bewusstsein für die Schwächen und Stärken. Da muss man ohnehin Schritt für Schritt vorgehen und die Abhängigkeiten evaluieren.

Wie haben wir die Ergebnisse ins Unternehmen getragen?

Matthes: Das Template wurde weiter ausgestaltet, vorgestellt und diskutiert. Als Plattform hat uns das Weekend of Nerds gedient, zu dem alljährlich unsere Entwickler zusammenkommen. Daraufhin haben wir es in verschiedenen Projekten angewendet und Erfahrungen gesammelt, haben Dinge gelernt und Schwachstellen gefunden.

Christian: In der täglichen Arbeit kann sich herausstellen, dass man das gefundene Template anpassen,  Aspekte in Frage stellen und den Weg der Veränderung weitergehen muss.

Matthes: Für uns ist wichtig, dass man die grundlegenden Punkte weiterträgt und nicht wieder verwirft. Es ist nicht in Stein gemeißelt wie es in der Praxis konkret aussieht. Es ist uns sehr wichtig unsere Ergebnisse in die Teams zu tragen und einen gemeinsamen und trotzdem individuellen Weg zu finden.

Christian, gab es Besonderheiten in der Zusammenarbeit?

Christian: Es war eine vertrauensvolle Zusammenarbeit. Ich habe mich sofort ins Team aufgenommen gefühlt und konnte mit allen Menschen bei queo ganz offen sprechen. Es war hier keine politische Arbeit involviert. Veränderungsprozesse brauchen Ehrlichkeit. Zu dem Zeitpunkt an dem wir auseinandergegangen sind, konnte ich das Ergebnis als sehr positiv bewerten. Matthes, an deinen Aussagen erkenne ich, dass ihr euch weiterhin mit dem Thema beschäftigt. Ich bewerte unsere Zusammenarbeit nicht daran ob die damalige Lösung zum jetzigen Zeitpunkt noch perfekt ist, sondern ob wir das Thema langfristig voranbringen konnten. Und damit bin ich sehr zufrieden. Festhalten muss ich auch, dass wir auf einem sehr hohen Niveau eingestiegen sind und uns sehr anspruchsvollen Themen gewidmet haben.

Matthes: Für uns waren die festen Termine und Aufgabenpakete sehr hilfreich.

Ralf: Ich finde es gut, dass man die Themen wirklich angeht. Es ist eine sehr kurzfristige Denke größere Schwerpunkte immer dem Tagesgeschäft unterzuordnen. Diese Denke ist zugegebenermaßen schwer abzustreifen.

Warum ist es wichtig, dass wir zusammengearbeitet haben, welche Effekte hat die Zusammenarbeit mit sich gebracht?

Ralf: Wir sind mit einem Ansatzpunkt aus dem Thema rausgegangen. Wir haben uns daraufhin einigen Workflow-Themen gewidmet, um die Testautomatisierung voranzutreiben. Es sind uns einige Punkte aufgefallen die wir optimieren wollen. Bei vielen Projekten sind wir nun soweit, dass die Testautomatisierung funktioniert. Vor allem für die Kernkomponenten laufen Basisakzeptanzkriterien und auch für Backend-Tests haben wir das abgebildet. Die Zusammenarbeit hat uns den Einstieg erleichtert und uns wissensmäßig vorangebracht.

Ist das Thema für einen Großteil unserer Projekte relevant?

Ralf: Für die großen Projekte. Bei den kleineren Projekten sollte man abwägen und nicht mit Kanonen auf Spatzen schießen. Bei unseren Großprojekten haben wir allerdings so viele Player und Stakeholder, dass wir es intensiv etabliert haben.

Erzeugt unser Vorgehen einen größeren Aufwand? Was hat sich im Arbeitsalltag verändert?

Ralf: Was man automatisiert muss man sonst manuell machen. Deswegen ist es eine schwierige Rechnung: Irgendjemand muss den Aufwand in Kauf nehmen. Die Automatisierung macht manuelles Testen aber unnötig und schafft Kapazitäten, die wir fürs Bugfixing und Co. aufwenden können. Es ist im Nachgang schwer zu sagen was wieviel Aufwand und Kapazität geschaffen hätte – man kann es nicht analysieren und eine Exceltabelle aufmachen. Das macht es im Controlling sicher nicht ganz einfach solche Sachen korrekt zu bewerten. Das „Nicht-Eintreten“ eines Ereignisses kann man schwer messen.

Matthes: Ein Aspekt den man nicht vergessen sollte: Wenn man manuell testet, dann kennen die Tester oft den Kontext und das Tool nicht. Das führt oft dazu, dass der Test schlecht gemacht wird. Für mich ist der schlechteste Fall, dass der Kunde einen Fehler findet. Denn dann sinkt das Vertrauen in die Lösung und die Unzufriedenheit steigt. Es ist für mich eine Qualitätsfrage. Der Kunde bekommt ein besseres Produkt – das muss man nicht einzeln verkaufen. Es sollte im eigenen Anspruch verankert sein.

Ralf: Wenn ein Entwickler die ganze Zeit über dieselben Sachen testet, dann wächst er mit den Fehlern mit. Er wird mit der Zeit viel fehlertoleranter. Eine Maschine macht das nicht. Sie toleriert nur das was man sie tolerieren lässt. Eine Maschine wird nicht betriebsblind. Wenn Entwickler sechs Monate an einer Anwendung arbeiten, dann werden sie manche Dinge nicht mehr wahrnehmen die jeder Außenstehende sofort sieht. Das ist bei jedem Menschen so.

Matthes: Bei großen Projekten kommt hinzu, dass man ein neues Produkt erarbeitet und Dinge umbaut. Das hat Auswirkungen auf andere Komponenten und Bereiche. Das hat der Entwickler auf keinen Fall im Blick. Tester, Konzepter oder Projektmanager haben das schon eher auf dem Schirm, aber können es vermutlich auch nicht ganzheitlich überblicken. Und da sind automatisierte Tests unabdingbar. Je komplexer ein Projekt wird, desto wichtiger ist es. Im Anforderungsbereich haben wir das definierte Vorgehen in unseren Projekten angewendet und festgelegt, dass es Ausnahmen gibt. Beispielsweise wenn das Team sich bewusst dagegen entscheidet. Mir als Schnittstelle zum Kunden hat es die Arbeit aber sehr erleichtert. Außerdem nutze ich diese Dokumentation, um den Entwicklern den Einstieg in die Tools zu erleichtern. Ich bin der Meinung, dass unser Vorgehen funktioniert. Ich kann nicht beweisen, dass es sich verbessert hat, aber mein Gefühl sagt mir, dass das Commitment von allen Seiten steigt.

Ralf: Was bei uns Einzug gehalten hat ist, dass im Confluence die Akzeptanzkriterien mit Gherkin abgebildet sind und gepflegt werden können. Ein Kollege hat per API eine Abfrage gebaut, die diese Kriterien in die Tests überträgt. Wenn sich dort was ändert, muss es also nicht an 80 verschiedenen Stellen gepflegt werden. Idealerweise baut das aufeinander auf – an anderer Stelle entstehen die Kriterien und die Technik automatisiert sie – damit sich bei Änderungen auch der Test ändert. Ein Code-Repository ist für den Entwickler super versioniert. Für jemanden der damit nicht so viel am Hut hat ist Git erstmal sehr kryptisch (Anmerkung Matthes: SVN auch). Wir wollten eine Lösung schaffen die beide Welten miteinander verbindet. Also haben wir gesagt: Im Wiki wird auch versioniert, man kann es nachvollziehen und Sachen wiederherstellen. Wir haben einen Prototypen gebaut der das ermöglicht. Wir wollen Barrieren einreißen, Barrieren zwischen technisch Beteiligten und „Nicht-technisch-Beteiligten“.

Werden wir künftig auch in weiteren Themen zusammenarbeiten? Gibt es dahingehend Wünsche?

Matthes: Klar gibt es Wünsche. Themen gibt es genug.

Christian: Der Anspruch der Qualität und Effizienz ist kein Zustand. Das ist immer ein Ziel, auf das man hinarbeiten muss. Die Themen gehen einem da sicherlich nie aus.

Ralf: Auf technischer Ebene haben wir es auf die Straße gebracht und nun geht es intensiv an einige Workflows. Die beiden Themen miteinander zu vereinen, da wird noch viel Arbeit reinfließen. Wir wollen auf hohem Niveau optimieren – Stillstand wird es nicht geben.

Fotos: Alexander Peitz