Tech Talk: „Technical Agile Enabling“ mit Pia Otter-Bäck von MIC

Tech Talk: „Technical Agile Enabling“ mit Pia Otter-Bäck von MIC

Mein Name ist Pia und ich erzähle Ihnen heute über unseren Technical Agile Ansatz bei der MIC. Kurz vielleicht zur MIC selbst: Wir sind Marktführer in Zoll-Softwarelösung. Gegründet wurde die Firma 1988. Wir haben 265 Mitarbeiter und bieten Zoll-Softwarelösungen für 48 Länder auf sechs Kontinenten an. Unsere Applikation wird von über 700 multinationalen Kunden verwendet.

Und jetzt zum Technical Agile Ansatz. Warum verfolgen wir ihn und welche Ziele haben wir damit? Generell wollen wir mit den Technical Agil Ansatz die guten technischen Praktiken in unserer Organisation etablieren, damit wir neue Features in kürzerer Zeit und mit besserer Qualität erstellen können. Wir wollen ein hohen qualitativen Code und effektive Entwicklungspraktiken und eine gesunde Unternehmenskultur unseren Entwicklern bieten und auch natürlich schauen, dass wir nicht in technischer Schuld ertrinken.

Was sind die Ziele der Technical Agile Enablings?

Wir wollen unsere technische Expertise erhöhen, eine kontinuierliche Lernenorganisation bieten und ein inspirierendes Arbeitsumfeld.

Genauso wollen wir natürlich die Qualität unserer Codebasis erhöhen, ein gemeinsames Verständnis unserer Probleme-Domäne schaffen und unsere Geschäftsagilität und Erfolg verbessern und erhöhen.

Die Praktiken, die uns dafür zur Verfügung stehen sind im MIC-Ansatz festgesetzt. Als T Technical Agile Enabler arbeite ich mit Teams für eine definierte Zeitperiode. Ich definiere mit den Teams ihre Codebasierten und ihre technischen Herausforderung und wir entscheiden uns, an was wir in dieser Zeitperiode arbeiten. Ich versuche verbesserte Entwicklungspraktiken in den Teams zu etablieren und was man dazu natürlich sagen muss: Es gibt nicht dafür das Pattern, dem generellen Ansatz, sondern das sind alles maßgeschneiderte Lösungen die dem Team effektiv helfen sollen bei ihrem Problem. Als Beispiel habe ich hier die Grafik ein bisschen gezeichnet. Wir arbeiten einfach als Teil des Teams. Wir sind bei den ganzen Scrum-Aktivitäten dabei. Wir helfen Ihnen bei größeren Herausforderungen mit z.B. ein User Story Mapping, organisieren Ensemble-Programming Sessions und Learning hours.

Uns stehen verschiedene Praktiken und Werkzeuge zur Verfügung. Ich habe hier mal ein paar zusammengefasst. Leider kann ich nicht über alle reden. Es ist aber durchaus interessant sich in manche hineinzulesen, um sich vielleicht weiter zu informieren. Das generelle ist es startet nicht nur bei codebasierten Design, sondern es fängt eigentlich beim Anforderungendesign an, geht zum Systemdesign bis zu Codedesign wo wir die Teams unterstützen können.

Zum Anforderungendesign habe ich mir behavior-driven Development rausgepickt, weil wir damit schon sehr gute Erfahrungen hatten. Hier geht es generell darum in eine Discovery wird die Anforderung von Pio, Tester und Entwickler erarbeitet und in Beispielen und Regeln zusammengefasst. In der Formulierung werden dann die Beispiele des Systemverhaltens dokumentiert und natürlich das in der Fachsprache, d. h. es versteht nicht nur ein Entwickler sondern eben auch der Kunde.

Automatisiert werden diese Dokumentationen dann in der Entwicklung des Features. Und so wird eine lebende Dokumentation geschaffen die das Systemverhalten automatisiert verifiziert.

Zum Systemdesign kann ich nur Domaindriven-Design empfehlen. Ich bin relativ begeistert davon. Es ist so, dass es hier darum geht, dass eben auch im Systemdesign die Domänenlogik ausschlaggebend sein sollte. Ich finde das Zitat da relativ hilfreich. Verständlich, dass eine Applikation, egal wie toll sie entwickelt ist, was für eine tolle Architektur sie besitzt, nur nutzbar und nützlich ist wenn sie das Problem löst.

Hier initiieren wir vor allem eben auch kreative Zusammenarbeit zwischen technischen- und Domänen-Experten, um so iterativ das konzeptuelle Modell wirklich in der Entwicklung verständlich zu machen.

Beim Test Design geht es vor allem darum, dass man hier nicht nur einen Test schreibt und denkt damit ist alles erledigt. Es geht vor allem darum, dass man über das Testing schon in der Architektur nachdenkt, dass man eine gute Test Kultur etabliert und am besten TDD praktiziert und vor allem auch einen nachhaltigen Testing-Ansatz wählt damit eben auch das Refactoring und die Wartung effizient sein können. Es ist ja auch einfach gut gesagt „Qualität ist kein Unfall“, sondern es ist immer das Resultat von einem intelligenten Ansatz. In Zusammenfassung kann ich sagen wir arbeiten als Technical Agile Enabler daran, dass die Teams besser zusammenarbeiten und einfach Spaß an ihrer Arbeit haben. Danke.