Live in Dortmund oder online bei Dir zu Hause

iterate=>RUHR

5. bis 6. November 2020

Über die Konferenz

iterate=>RUHR ist eine Konferenz für Software Entwicklung mit Fokus auf Softwarequalität, Clean Code und Testing. Die Konferenz ist eine zwei tägige Veranstaltung mit dem Ziel anwendungsbezogene Fähigkeiten zu vermitteln, Einblicke in die Praxis der Softwareentwicklung zu geben und Möglichkeiten zum direkten Austausch mit anderen Menschen anzubieten. Sie bekommen einerseits den pragmatischen Einblick in die Softwarequalität und andererseits einen Raum für Inspiration und Austausch abseits Ihres Projektalltags.

Die Konferenz wird im Rahmen der Digitale Woche Dortmund stattfinden. Der Session-Tag wird am 05. November hybrid statt finden. Durch ein Hybrid-Modell wird der Teilnehmer in der Lage sein, entweder vor Ort in Dortmund daran teilzunehmen oder dem Live-Stream zu Hause zu erleben. Der Workshop-Tag wird  am 06. November vor Ort in Dortmund stattfinden. In Dortmund werden wir sicherlich und selbstverständlich nach allen Regeln dafür sorgen, dass die aktuellen Hygiene-Maßnahmen angehalten werden.

Hier findet ihr mehr zu dem Hygiene-Maßnahmen unserer Location: https://top-tagung.de/coronavirus/

Agenda

Session Tag

Donnerstag, 05.11.2020 - Sessions Übersicht

8:00AM

Check In

8:00AM - 9:00AM

Eine andere Perspektive mit digitaler Transformation: Kopf schlägt Kapital (Eröffnungs-Keynote)

- 45 min

Peter Rossbach

Eine andere Perspektive mit digitaler Transformation: Kopf schlägt Kapital (Eröffnungs-Keynote)

-45 min

Peter Rossbach

Thanks for watching!

Von Ärzten, Piloten und Flugzeugen: Was kann Softwareentwicklung von anderen Berufen lernen?

- 45 min

Christian Seifert

Von Ärzten, Piloten und Flugzeugen: Was kann Softwareentwicklung von anderen Berufen lernen?

-45 min

Christian Seifert

"Software ist aus unserer Welt nicht mehr weg zu denken. Dennoch fühlt es sich häufig so an, als wüssten wir noch immer nicht wirklich, wie Softwareentwicklung denn nun ""richtig"" funktioniert. Wir vergleichen oft und gerne das Erstellen einer Anwendung mit der Herangehensweise von Handwerkern an ein Projekt, was sich bereits durch unser Vokabular zeigt: Wir ""bauen"" Anwendungen, ""verdrahten"" Systeme, ""schrauben"" an Infrastruktur und ""basteln"" Workarounds um bestehende Probleme zu lösen. Es tut uns daher gut einmal über den eigenen Tellerrand zu schauen und zu vergleichen, wie andere Berufsgruppen es schaffen dauerhaft gute Qualität sicher zu stellen. Schließlich werden viele Dinge, die für einen Handwerker selbstverständlich sind, in der Softwareentwicklung oftmals nicht oder nur am Rande beachtet. Manches wird schlicht und ergreifend ignoriert oder ""kreativ"" (um)gedeutet. Doch warum eigentlich? Viele Berufe haben seit Jahrzehnten (wenn nicht Jahrhunderten) passende Hilfsmittel und ""Best Practices"" entwickelt um für sie typische Herausforderungen und Probleme besser und einfacher lösen zu können. Gerade in der Luftfahrt kommt es auf Präzision und Verlässlichkeit an. Wer möchte schon hören, dass der Flug in den Urlaub gestrichen wurde, nur weil die Wartung nicht korrekt durchgeführt wurde oder ein Test fehlgeschlagen ist? Ähnlich verhält es sich bei Ärzten oder Pflegepersonal: Fehler oder Nachlässigkeit können hier im wahrsten Sinne des Wortes schnell tödlich enden. Für uns Softwareentwickler lohnt es sich daher einen genaueren Blick auf die Arbeit von Flugzeugmechanikern, Piloten oder auch Ärzten zu werfen und uns von ihnen die ein oder andere Inspiration zu holen, die uns hilft unseren Entwicklungsprozess zu optimieren und den Stress, der sich immer wieder in Entwicklungsprojekten zeigt, zu bändigen. Der Vortrag gibt Tipps und Hinweise, wie man gewohnte Prozesse innerhalb der Entwicklung hinterfragen, optimieren und vereinfachen kann. Nicht ohne ein wenig Selbstironie werden Konzepte, Methoden und Werkzeuge vorgestellt, die die es allen Beteiligten erlauben das ""Software-Haus"" stabiler und langlebiger zu bauen.

Psychocode – die Legacy IT-Wartungshölle

- 45 min

Christoph Meyer
Remote

Psychocode – die Legacy IT-Wartungshölle

-45 min

Christoph Meyer
Remote

Wartung von Legacy-Projekten kann ein Albtraum sein: fehlende Tests, kaum Dokumentation, verworrene Codestrukturen ohne Ende, dafür produktiv und dank Vertriebs- und Kundendrucks hochgradig kritisch. Das ursprüngliche „Tiger-Team“ junger motivierter und hart arbeitender Entwickler wurde im Laufe der Jahre immer weiter reduziert und geändert. Wissensträger haben die Firma verlassen und die veraltete Technik wird von der nachfolgenden Generation weder verstanden noch akzeptiert. Für die verbleibenden Entwickler, die jahre- bis jahrzehntelang diesen Codehaufen verstehen, verändern und betreiben müssen, kann sich das wie eine Strafarbeit anfühlen, die einfach nicht enden will. Ein mir bekannter Software-Architekt verglich diesen Zustand einmal mit einem Teich, der im Laufe der Jahre mit Seerosen zuwächst, bis er schließlich „umkippt“ und alle Fische sterben. Für Management und Entscheider scheint oberflächlich lange alles gut zu sein, doch wenn Moral und Engagement im Team schwinden, steigt die Fehlerrate und bei zunehmendem Druck auch die Fluktuation. Aus diesen Gründen ist es wichtig, zu verstehen, welche Wechselwirkungen es bei der Wartung von Legacy-Projekten niedriger Qualität zwischen Psyche und Technik gibt, welche Phasen ein Legacy-Projekt durchläuft und welche Maßnahmen man ergreifen kann, bevor der „Teich mit Seerosen zuwächst“.

Langlebige Softwarearchitekturen – ohne Schulden die Jahrzehnte überdauern

- 75 min

Dr. Carola Lilienthal

Remote
75 min

Langlebige Softwarearchitekturen – ohne Schulden die Jahrzehnte überdauern

-75 min

Dr. Carola Lilienthal

Remote
75 min

Heute entwickeln niemand mehr Software auf der grünen Wiese, sondern man repariert, erweitert, verändert und baut vorhandene Software aus. Weil der Code immer komplexer wird, fangen wir an, Erweiterungen zu programmieren, von dem wir wissen, dass sie aus Architektursicht schlecht ist. Aber das ist die einzige Lösung, die, wenn wir Glück haben, noch funktioniert. In diesem Vortrag erfahren Sie, wie Sie Ihre alte Codebasis Schritt für Schritt auf den Pfad der Tugend zurückbringen können, so dass Wartung wieder Spaß macht.

Lesbare Tests in Java mit AssertJ

- 45 min

Thomas Traude

Lesbare Tests in Java mit AssertJ

-45 min

Thomas Traude

AssertJ ist ein komfortables und mächtiges Werkzeug für das Schreiben von Tests in Java. Als Alternative zu Hamcrest liefert es eine Fülle an Möglichkeiten, mit denen das Testen dem Entwickler noch mehr Spaß macht. Die Session bietet einen Einstieg in AssertJ und zeigt auch fortgeschrittene Funktionen. Mit viel Live Coding werden anhand von Beispielen verschiedene Highlights vorgestellt. Dabei gibt es immer wieder Tipps, wie wir Tests lesbar und wartbar gestalten. Die Teilnehmer können nach der Session das Gezeigte direkt in ihrem Projekt anwenden.

Bin ich eine Pfeife, wenn ich kein Experte bin?

- 45 min

Anika Zohren

Bin ich eine Pfeife, wenn ich kein Experte bin?

-45 min

Anika Zohren

"Ich muss nicht freundlich zu den Leuten sein”, erklärte mir neulich ein Kollege. “Ich bin der einzige Experte zu dem Thema hier. Die kommen trotzdem immer wieder, wenn sie was brauchen.” Zuvor hatte jemand unser Gespräch mit einer Frage unterbrochen und wurde von ihm ziemlich abgekanzelt. Der Hang zum Expertentum ist in Deutschland sehr verbreitet, stellt auch Justin Vaughan-Brown in seinem auf heise Developer erschienenen Artikel “Verträgt sich DevOps mit der deutschen Arbeitskultur?” fest. Doch macht das Expertentum überhaupt Sinn in der sich so schnell wandelnden digitalen Welt? Und ist unser Arbeitsalltag nicht zu stressig, um auch noch die Bürde auf uns zu nehmen, alles über ein Thema zu wissen und keine Fehler zu machen, damit unser Experten-Image nicht beschädigt wird? Die Wirtschafts-Profilerin Suzanne Grieger-Langer erzählt uns andererseits von sogenannten “Pfeifen”, die keine Ahnung von der Materie haben, jedoch ziemlich erfolgreich sind. Sie managen ihr Auftreten und nicht ihr Wissen und werfen mit Schlagworten um sich. Doch bin ich eine Pfeife, wenn ich kein Experte sein möchte? Oder gibt es etwas dazwischen?

How to measure code quality?

- 45 min

Juliana Stepanova, Inna Yakovenko

English

How to measure code quality?

-45 min

Juliana Stepanova, Inna Yakovenko

English

The development team owns the quality of delivered software. How can the team ensure producing the best code quality and what Scrum Master needs to know for the coaching of the team to improve this process? To support the development team Scrum Master should take a critical look at different factors of code quality and assist the team to discover relevant metrics. Verifying code quality metrics is another important aspect, which leads to measurements that are beneficial for the development team and valuable stakeholder. This session offers you an overview of theoretical methods and their practical realization as well as the introduction of the best practice of improving code quality.

Wie gut ist eigentlich unser Code?

- 45 min

Martin Hüser

Wie gut ist eigentlich unser Code?

-45 min

Martin Hüser

Vor ein paar Jahren hat unser Management gefragt, wie gut eigentlich unser Code ist und ob wir das nicht mal mit Sonarqube messen könnten? Der Vortrag beschreibt, was Sonarqube ist, wie wir es eingeführt haben, heute nutzen, was wir dabei gelernt haben, Sonarqube auf eine große, gewachsene Codebasis von C++ und C# Code loszulassen und ob es diese Frage überhaupt für uns sinnvoll beantworten kann.

Unit tests as an overkill

- 45 min

Kartik Adur

English

Unit tests as an overkill

-45 min

Kartik Adur

English

Frontend Development is like the wild wild west, no laws except the ones you make. Uncontrolled and running rampant, code can often be unpredictable and buggy. TDD makes it better. Predictable outcomes with a static upfront sunk cost, but rigid and unforgiving to anyone that is not a Master. Sure it would tell you where the issues in your code are, but how much time and effort would you be willing to put towards it? And what about when requirements change? Sadly the reality of coding professionally often leaves very little time for actual coding. Maybe there is a middle path with Typed Objects and Linting as a compromise. BDD only for the more complex parts of the code would help reduce the overhead for mocks, stubs, and test setups. Testing for what the user perceives on their screen rather than what is happening under the hood. Ensure code fails the right way while reducing the required complexity and overhead.

Wie sage ich es meinem Tester?

- 45 min

Andrej Thiele

Wie sage ich es meinem Tester?

-45 min

Andrej Thiele

In vielen Projekten sind Entwickler und Tester nach wie vor von einander getrennt und arbeiten für sich alleine, ohne ernsthaft miteinander zu kommunizieren. Das Problem an diesem Ansatz ist, dass beide Gruppen sich meistens nicht vertrauen und Vorurteile gegenüber den anderen haben. Dies ist insbesondere dann der Fall, wenn in der entsprechenden Firma eine Kultur der Schuldzuweisung vorherrscht, in der primär nach Schuldigen für Probleme und weniger nach Lösungen gesucht wird. In diesem Vortrag werden die Ergebnisse von Interviews mit Entwicklern und Testern vorgestellt, in der beide Gruppen zu Wort kommen sollen. Es ist der Versuch, eine Brücke zu schlagen und für das Verständnis für die Probleme beider Gruppen zu werben, um so den Keim für einen Kulturwandel zu legen.

Clean SQL - Quality Time für Abfragesprachen

- 45 min

Lena Rother
Remote

Clean SQL - Quality Time für Abfragesprachen

-45 min

Lena Rother
Remote

(Ein Talk über die Anwendung von Clean Code Prinzipien und Praktiken in SQL und verwandten Abfragesprachen) “It is not enough for code to work.” (Robert C. Martin) – das gilt nicht nur für objektorientierte Sprachen, sondern für alle Teile von Software, die einen Anspruch auf hohe Qualität haben. Obwohl der SQL-Standard permanent weiterentwickelt wird, hat die Abfragesprache als solche ein eher verstaubtes Image. Kein Wunder, schließlich bieten Frameworks wie Spring Data durch konfigurierbares, objekt-relationales Mapping tatkräftige Unterstützung. Dennoch finden wir im Code verkettete Strings und Aufrufe von Datenbankprozeduren. Ich möchte mit Ihnen diskutieren, warum das so ist und welche Praktiken uns dabei weiterhelfen. Neben diesen Erfahrungen habe ich einige Fallstricke und hilfreiche SQL-Funktionen im Gepäck. Ich freue mich auf unseren Austausch!

Den Kommentar hättest Du Dir sparen können!

- 45 min

Stefan Hock

Den Kommentar hättest Du Dir sparen können!

-45 min

Stefan Hock

Das ist doch ein Spruch, den Eltern gerne mal ihren pubertierenden Töchtern entgegen schmettern. Aber zu oft möchten wir dies auch unseren Kollegen zu rufen. Also wollen wir uns in diesem Vortrag mal die Frage stellen, wie sinnvoll oder böse Kommentare im Quellcode denn sind. Aber Vorsicht! Der Vortragende ist bei dem Thema voreingenommen, lässt aber gerne mit sich reden. Zunächst soll betrachtet werden, welche Arten von Kommentaren es gibt. Kommentare die… Code beschreiben Metadaten beinhalten Code deaktivieren (auskommentieren) visuell wahrgenommen werden (e.g. Ascii Art, Linien, Farbe) Emotionen vermitteln Welche Probleme verursachen diese Kommentare bei zukünftigem Lesen und der weiteren Arbeit im Code? Welche Kommentare sind tatsächlich wichtig? Das alles wird unterlegt mit vielen Praxisbeispielen, manche zum Lachen, manche zum Weinen, aber alle zum Nachdenken.

DevSecOps Intro

- 45 min

Sven Ruppert

DevSecOps Intro

-45 min

Sven Ruppert

Wo genau liegen die Unterschiede zwischen DevOps und DevSecOps? Aus welchen Komponenten besteht es, an welcher Stelle in meiner Wertschöpfungskette macht es Sinn und wie kann es mir bei meinem Business helfen? Welche Do´s and Dont´s kommen auch mich zu und welche Werkzeuge können mir helfen. Und wie sieht das alles für mich als Softwareentwickler im täglichen Leben aus? Wenn Dich das interessiert, dann bist Du in diesem Talk genau richtig.

Stop using TDD — it is poisonous

- 45 min

Slawa Gladkow

English

Stop using TDD — it is poisonous

-45 min

Slawa Gladkow

English

Just stop, stop with Test Driven Development! There are good chances that you’ll get used to it, prove for yourself all its benefits and could not work anymore in “old” fashion. Sadly, but not every company would accept your high quality approach to software engineering and be willing to invest in that. While developing software quality of the code plays a significant role. One of the most reliable ways to improve quality is to use Test-Driven Development, or simply TDD — almost two decades old technique to develop software “test-first”. A technique which is still not widely used, but why? There are many reasons for that like type of the software project, available resources, training and knowledge transfer, time budgets, intrinsic software complexity etc. That’s what this session about. After a brief introduction to the topic, we will discuss pros and cons of TDD, its application areas, differences between test first and test last, best practices, ways how to convince dev team or stakeholders, tips on how to ice-brake with TDD in your organisation and how to be sure that it works and works well.

Zu viel des Guten – Agile Coaches als Mobbing-Treiber

- 45 min

Gerrit Beine

Zu viel des Guten – Agile Coaches als Mobbing-Treiber

-45 min

Gerrit Beine

Wir Agilisten sind begeistert von kontinuierlicher Verbesserung, demokratischen Unternehmensstrukturen und Achtsamkeit im Umgang mit anderen Menschen. Toleranz, Lösungsfokussierung und Respekt sind Werte, die sofort alle teilen möchten. Aber was passiert, wenn Menschen, die nicht an der Achtsamkeitsübung teilnehmen wollen, plötzlich ausgegrenzt werden? Was passiert, wenn positive Psychologie Menschen zu Abgründen zurückführt, die sie eigentlich schon überwunden hatten? Was passiert, wenn falsch verstandene Konzepte der Sozial- und Organisationspsychologie mehr kaputt machen, als sie helfen? In diesem Vortrag möchte ich ein paar Erlebnisse teilen, die zum Teil schon grenzwertig waren – und Erklärungen anbieten und Wege, wie man als Agile Coach solcherlei vermeiden kann.

Verhaltensbezogene Codeanalyse

- 45 min

Sven Torben Janus
Remote

Verhaltensbezogene Codeanalyse

-45 min

Sven Torben Janus
Remote

Wenn es um Design in der Softwareentwicklung geht, sind sich die meisten einig, dass wir Softwarearchitekten und -entwickler die Experten für diesen Job sind. Im Gegensatz dazu lässt sich jedoch beobachten, dass wir Experten übermäßig viel über technische Schulden diskutieren. Schulden, die wir im Laufe der Historie in ihre Software eingeführt haben und (hoffentlich) versuchen wieder abzubauen. Beim fachlichen Design unserer Anwendung spielen Domänenexperten für die Erarbeitung unseres Domänenwissens eine entscheidende Rolle. Was wir dabei häufig vergessen, ist, dass wir Entwickler im Laufe der Zeit mit die erfahrensten Domänenexperten werden. Die Historie unseres Codes sollte daher unsere Erfahrung zu bestimmten Zeitpunkten und damit auch unseren Lernprozess über die Fachdomäne widerspiegeln. Wenn wir Entwickler als (Domänen-)Experten jedoch eben diejenigen sind, die technische Schulden in die Software einführen, müssen wir die Frage aufwerfen, wie viele fachliche Schulden bzw. Modellierungsschulden wir im Laufe der Zeit eingeführt haben. Bei der Analyse von Schulden tendieren wir dazu, den aktuellen Status unseres Modells zu betrachten. Wir versuchen vorherzusagen, wie das Modell in Zukunft aussehen könnte oder sollte. Dabei ignorieren wir jedoch eine große Wissensquelle; die Historie unseres Codes. Es ist mir ein Rätsel, warum wir diese Code-Historie selten berücksichtigen, wenn wir unsere Fachdomäne (neu)erlernen oder sie (neu)gestalten, um zukünftige Geschäftsanforderungen zu erfüllen. In diesem Vortrag lernt ihr, warum technische Schulden nicht technisch sind. Ihr werdet sehen, warum die Code-Historie für eine Analyse von Schulden wichtig ist und was das alles mit unserem Verhalten zu tun hat.

Gemeinsam statt Einsam – kollaboratives Testen in der Praxis

- 45 min

Katharina Warak, Benedikt Wörner

Gemeinsam statt Einsam – kollaboratives Testen in der Praxis

-45 min

Katharina Warak, Benedikt Wörner

In Projekten hören wir immer wieder folgende Statements: „Die Idee des Explorative Tests ist zu abstrakt! Reviews sind langweilig! Die Stakeholder geben nie Feedback!“ Eine Lösung sind kollaborative Testmethoden. Sie sind leichtgewichtig, können schnell erlernt und in diversen Situationen eingesetzt werden. Sie verbessern die Kommunikation und bauen Wissensinseln ab und den Team-Spirit auf. Anhand von drei Problemstellungen wird erklärt, wie die kollaborativen Testmethoden Pair Testing, Bug Bash und Mob Testing funktionieren: Situation 1: Im Verlauf der Zeit haben sich Wissensinseln im Projekt gebildet. Diese müssen abgebaut werden. Die Zeit drängt, da einer der Experten im Projekt bald in Rente ausscheidet und Wissen transferiert werden muss. Ein Lösungsansatz hierfür ist Pair Testing. Situation 2: Das Entwicklungsteam für ein technisch hoch komplexes System entwickelt und hat die meiste Zeit der Entwicklung mit der Lösung der technischen Anforderungen verbracht, auf die Usability hat dabei keiner wirklich geachtet. Eine Bug Bash hat ihre Stärken im Bereich Usabiltity Testing und könnt hierfür eine Lösung sein. Situation 3: Am Ende eines Releases gehört es zu den Projektaufgaben, dem Fachbereich die neu umgesetzten Funktionalitäten vorzustellen. Bisher geschah dies immer anhand eines Folienvortrages. Dies war nicht nur für den Kollegen, der es vorstellen sollte, anstrengend, sondern auch für den Fachbereich langweilig. Meist ging die Aufmerksamkeitskurve bereits nach wenigen Minuten deutlich nach unten. Eine weitere Möglichkeit zum Wissenstransfer in größeren Gruppen ist die Methode Mob Testing. Jede der einzelnen Methoden wird zunächst methodisch vorgestellt, anschließend folgt eine Betrachtung eines Projekteinsatzes, gefolgt von Vor- und Nachteilen der Methode.

Unit Testing im Brownfield? Challenge accepted!

- 45 min

Andreas Richter

Remote

Unit Testing im Brownfield? Challenge accepted!

-45 min

Andreas Richter

Remote

Unit Testing ist mittlerweile in fast jedem Entwicklerkopf angekommen. Das ist gut so. Die Grundlagen sind leicht erlernt, ein geeignetes Testing Framework schnell gefunden und die Einarbeitung dank oftmals guter Dokumentation auch kein Hexenwerk. So gewappnet meistert man das eine oder andere Kata mit Bravour und in Greenfield Projekten kann man sein Wissen voll auskosten und so eine ausreichend gute Test Coverage erreichen. Doch wie sieht das Ganze in gewachsenen Systemen aus? Dort wo die Logik weit im Quellcode verstreut und schwer zu finden ist? Wie erreicht man dort eine ausreichend gute Testabdeckung? Und was zum Henker ist in einem historisch oder gar hysterisch gewachsenen System überhaupt alles zu testen? In dieser Session zeige ich, wie einige der SOLID Prinzipien, gepaart mit der Onion Architecture und Building Blocks aus dem DDD Universum helfen können, ein gewachsenes Tohuwabohu schrittweise in ein gut testbares System umzubauen.

Custom JUnit5 Testengine

- 45 min

Sven Ruppert

Custom JUnit5 Testengine

-45 min

Sven Ruppert

JUnit5 bring uns einig neue Möglichkeiten und die beiden TestEngines ermöglichen den Einsatz in fast allen Bereichen der testgetriebenen Entwicklung auf der JVM. Alte Projekte profitieren von der Vintage-Engine und es kann fast immer der Bestandsquelltext basierend auf JUnit4 ausgeführt werden. Die Jupiter-Engine gibt einem alle Neuen Funktionen die das JUnit5-Team uns bereitstellt. Für die meisten Fälle ist es sehr angenehm und bietet die notwendige Flexibilität. Aber es gibt eben auch noch die anderen Projekte, die eben nicht mit dem Standart ausreichend versorgt sind. Jedoch auch hier bietet jUnit5 einen sehr starken Ansatz. Die Rede ist von der Möglichkeit, eigene Testengines in jUnit5 einzubinden. Aber was genau kann man nun damit machen? Welche Möglichkeiten ergeben sich und wann macht es überhaupt Sinn eine eigene Testengine zu entwickeln? In dieser Session werden wir uns genau dieser Fragestellung zuwenden und unterschiedliche Einsatzmöglichkeiten und deren Implementierung ansehen.

Effizient arbeiten mit Architecture Decision Records (ADRs

- 45 min

Johannes Dienst
Remote

Effizient arbeiten mit Architecture Decision Records (ADRs

-45 min

Johannes Dienst
Remote

Dokumentation gehört oft nicht zu den Lieblingsaufgaben im Softwareentwicklungsalltag. Das resultiert in vielen Fällen daraus, da nicht klar ist, warum etwas dokumentiert werden sollte. Der in der Praxis gelebte Ansatz einen Dokumentationsort, zum Beispiel in Form eines Wikis, ist zum Scheitern verurteilt. Entweder es wird kaum dokumentiert oder zu viel und es wird schwer Informationen zu finden, die man sucht. Ein leichtgewichtiger Ansatz ist arc42, bei dem je nach Bedarf die vorgegebenen Unterpunkte ausgefüllt werden. Dort werden im Unterpunkt neun Entwurfsentscheidungen dokumentiert, also genau die Entscheidungen, die die Softwarearchitektur entscheidend prägen. Die Auswirkungen von nicht dokumentierten Entscheidungen gehen von immer wiederkehrenden Diskussionen, bis hin zu fehlerhaften Folgeentscheidungen die das Projekt zum Scheitern bringen können. Doch wie können viele Entscheidungen effizient und nachvollziehbar dokumentiert werden? In diesem Vortrag wird ein kompaktes Format namens Architecture Decision Records (ADR) vorgestellt und gezeigt, wie sie effizient eingesetzt werden können. Neben Kleinigkeiten wie der Titelvergabe für eine ADR wird ein Lösungsvorschlag aufgezeigt, um bei einer großen Sammlung von Entwurfsentscheidungen (>50) nicht den Überblick zu verlieren. Dabei kommt der Docs-As-Code Ansatz mit AsciiDoc und JBake zum Einsatz, mit dem die technische Architektur in einer Microsite gerendert wird. Durch Tagging und eine effiziente Suche, wird die Dokumentation nicht nur lebendig, sondern zum täglichen Arbeitsmittel.

Historisch gewachsen – wieso lassen wir systematisch unseren Quellcode verwildern?

- 45 min

Ursula Krischik

Historisch gewachsen – wieso lassen wir systematisch unseren Quellcode verwildern?

-45 min

Ursula Krischik

“Historisch gewachsen” ist die Antwort auf all unsere Entwicklungssünden. Welche Rahmenbedingungen, Entscheidungen und Verhaltensweisen führen dazu, dass alte aber auch neue Projekte immer mehr verwildern? In meinem Vortrag beleuchte ich die Ursachen und zeige Wege aus dem verwucherten Irrgarten.

Testgetriebenes Management – Was Manager von der Softwareentwicklung lernen können

- 45 min

André Claaßen

Testgetriebenes Management – Was Manager von der Softwareentwicklung lernen können

-45 min

André Claaßen

Machen wir uns nichts vor: Obwohl weder Scrum noch das agile Manifest Manager kennen, tauchen in vielen Unternehmen Manager sehr wohl auf. Aber auch in den lateralen agilen Rollen, wie beim Product Owner und dem Scrum Master, ist Führung und die Verfolgung von Zielen überaus wichtig. Statt also gegen das Management zu wettern, wäre eine kluge Einbindung und Zusammenarbeit sehr wichtig. In meinem Vortrag zeige ich, was Manager und Führungskräfte von Software-Entwicklern und insbesondere vom Extreme Programming lernen können. Ich nenne es Testgetriebenes Management. Wie und warum das richtig gut funktioniert, erkläre ich in meinem Vortrag.

Cloud = teuer oder aufwendig? Das muss nicht sein – Einführung in Rancher

- 45 min

Morris Janatzek

Cloud = teuer oder aufwendig? Das muss nicht sein – Einführung in Rancher

-45 min

Morris Janatzek

Rancher
18:00

Abschluss

18:00 -

Workshop

Freitag, 06.11.2020 - Workshop Übersicht

08:00

Check-In

08:00 - 09:00

Why so serious? Games-Room

- 6-8 Stunden

Björn Meschede

6-8 Stunden

Why so serious? Games-Room

-6-8 Stunden

Björn Meschede

6-8 Stunden

Wer aus Einzelnen ein Team – und noch dazu ein erfolgreiches – formen will, muss Menschen überzeugen, motivieren und nicht zuletzt eine Menge Veränderungen anstoßen und begleiten. Lernspiele, auch Serious oder Agile Games, können dabei einen wertvollen Beitrag leisten: Sie lassen Menschen in kurzer Zeit wertvolle Erfahrungen machen, setzen gezielt Impulse und können ungeahnte Kreativität freisetzen. Mit der richtigen Moderation und dem passenden Debriefing sind sie oftmals sogar effizienter als klassische Lehrmethoden. Und nicht zuletzt machen sie eine Menge Spaß! Neugierig geworden? Dann nutzen Sie die Gelegenheit und besuchen Sie den „Games Room“ auf der Iterate.Ruhr! Dort moderiert der Clean Code Coach und Serious Games Facilitator Björn Meschede Spiele zu verschiedenen Aspekten rund um Teamentwicklung, Agilen Methoden, Clean Code und Testing.

Spielend Agil und Remote Teamarbeit in Corona Zeiten

- 6-8 Stunden

Spielend Agil und Remote Teamarbeit in Corona Zeiten

6-8 Stunden

Spielend Agil und Remote Teamarbeit in Corona Zeiten

-6-8 Stunden

Spielend Agil und Remote Teamarbeit in Corona Zeiten

6-8 Stunden

Spielend Agil (Workshop – Teil 1) Kurze Zusammenfassung agiler Vorgehensweisen und Spiele zum interaktiven Erleben Theorie: agiles Manifest, agile Werte  Spiel: Selbstorganisation Theorie: Scrum (in a nutshell)  Spiel: Ballpoint Game Theorie: Kanban und Lean (in a nutshell)  Spiel: Marshmellow Challenge Agile Mindset Remote Teamarbeit in Zeiten von Corona (Workshop – Teil 2) Der Transfer eines (Teil-)Teams von der analogen in die virtuelle Welt. Ein eingespieltes Team für ein paar Wochen ins homeoffice zu schicken kann problemlos funktionieren, wenn Das Team bereits eine Teamkultur hat Diese Teamkultur in die virtuelle Welt „transferiert“ wird. Hier gebe ich ein paar Tipps, wie das gut gelingen kann. Remote Onboarding und Kennenlernen Was aber, wenn das Team neu geformt wird und plötzlich ist Shutdown? Wie kann man virtuell neue Teammitglieder onboarden und im Team remote Teambuilding machen? Ich zeige Remote Networking Kennenlern-Spiele, die remote gespielt werden können Beyond Tools –virtuelles Teamwork im Alltag Tipps für effiziente online-Meetings Non-verbale Kommunikation über Videokonferenz

JUnit Jupiter als Entwickler Werkzeug und nicht als Test Framework

- 6-8 Stunden

Karl-Heinz Marbaise

6-8 Stunden

Event Storming für Tester

- 4 Stunden

Andrej Thiele, Sven Torben Janus

4 Stunden

Event Storming für Tester

-4 Stunden

Andrej Thiele, Sven Torben Janus

4 Stunden

In den letzten Jahren hat sich Event Storming zum deFacto Standard im Domain Driven Design entwickelt. Aber leider werden in den meisten Fällen die Business Prozesse ohne die dazugehörigen Tests modelliert. Die auf diese Weise entwickelten Modelle werden für die Klärung der Zusammenhänge innerhalb der Domäne und für die Entwicklung einer funktionsfähigen Software verwendet, ohne zu berücksichtigen, dass man damit zusätzlich auch sinnvolle und signifikante Tests erstellen kann. In diesem Workshop werden wir daher versuchen, diesen fehlenden Schritt zusammen mit den Teilnehmern zu gehen und entsprechende Tests zu entwickeln. Dazu nutzen wir die Möglichkeiten des Event Stormings für die Entwicklung von Testfällen im BDD Stil und werden mit Hilfe der typischen Event Storming Elemente wie Kommandos, Aggregate und Events die Business Test für unsere Domäne erstellen.

Schulen der Test-getriebenen Entwicklung

- 6-8 Stunden

Marco Emrich

6-8 Stunden

Schulen der Test-getriebenen Entwicklung

-6-8 Stunden

Marco Emrich

6-8 Stunden

In der Test-getriebenen Entwicklung sind seit vielen Jahren die Chicago und die London-School vorherrschend. Nachdem die Münchner Schule 2018 ein neues Konzept ergänzte, folgten im vergangenen Jahr die Hamburger und die St. Pauli-Schule. Diese fünf (mindestens?) TDD-Schulen unterscheiden sich grundlegend in ihrer Methodik. Dennoch schließen sie sich nicht gegenseitig aus. In diesem Workshop habt ihr die Gelegenheit, die verschiedenen Schulen kennen zu lernen und zu erfahren, welcher Ansatz sich in welchem Kontext am besten eignet. Nach einer kurzen Einführung probieren wir die verschiedenen Ansätze gemeinsam im Pair- oder Mob-Programming aus. Dadurch lernt ihr nicht nur die theoretischen Grundlagen kennen, sondern übt auch gleich den praktischen Einsatz.

UX-Workshop Create things that matter – and how to figure it out

- 6-8 Stunden

Judith Strunk

6-8 Stunden

UX-Workshop Create things that matter – and how to figure it out

-6-8 Stunden

Judith Strunk

6-8 Stunden

„Wenn ich die Menschen gefragt hätte, was wollen, hätten sie gesagt schnellere Pferde“ – Henry Ford. Wer wirklich fantastische Produkte bauen will, die einen echten Mehrwert für die Kunden bringen, muss herausfinden, was sie wirklich brauchen. Und wer kennt es nicht? Der Kunde wünscht sich etwas, es wird genauso umgesetzt, aber am Ende ist er doch unzufrieden. Nenn es Agil, DDD oder UX – der Gedanke ist immer der gleiche: du musst verstehen worum es geht und deine Ideen möglichst schnell ausprobieren. In diesem Workshop lernst du Methoden wie du dieses Ziel erreichen kannst. Du wirst mit den anderen Teilnehmern gemeinsam ein, von Grund auf, neues Produkt kreieren. lernen, wie du deine Ideen schnell testen kannst und zu den tatsächlichen Nutzungsanforderungen kommst. Von EntwicklerIn bis strategischem Produktmanagement – Dieser Workshop richtet sich an alle die Produkte entwickeln wollen, die begeistern.

Eine kurze Einführung in Testing mit ASP.NET Core und Entity Framework Core

- 4 Stunden

Sebastian Kleinschmager

4 Stunden

Eine kurze Einführung in Testing mit ASP.NET Core und Entity Framework Core

-4 Stunden

Sebastian Kleinschmager

4 Stunden

Ich bin ein Freund von leichtgewichtigen, aber gut test- und wartbaren Strukturen. In diesem Workshop schauen wir uns in kurz und prägnant einen Satz an Tools und Libraries an, die wir nutzen können, um eine ASP.NET Core Webanwendung mit dahinter liegender Datenbank möglichst einfach im Entwicklungsalltag strukturieren und testen zu können. Dabei gehen wir auch kurz auf den Test-First Ansatz ein und versuchen diesen schon von der ersten Aufgabe an umzusetzen. Wir lernen sowohl Mechanismen zum Schreiben von klassischen “Unit Tests”, als auch von eher integrativen Tests kennen. Nicht dogmatisch, sondern pragmatisch, und immer mit dem Ziel einer einfach lesbaren und wartbaren Software. Kenntnisse in C# und .NET Core sind hilfreich aber grundsätzlich nicht zwingend. Erfahrung in Programmierung sollte aber definitiv vorhanden sein, denn ich setze das Wissen über objektorientierte Konzepte größtenteils voraus.

Einführung in SapphireDb – Alternative zu Firestore/Firebase Realtime Database für Asp.Net Core

- 4 Stunden

Morris Janatzek

4 Stunden

Einführung in SapphireDb – Alternative zu Firestore/Firebase Realtime Database für Asp.Net Core

-4 Stunden

Morris Janatzek

4 Stunden

SapphireDb ist eine Erweiterung für Asp.Net Core und Entity Framework Core und stellt einfach zu verwendende Funktionen einer Echtzeit Datenbank wie bspw. Firestore zur Verfügung. Sie ist über eine einfache API ansprechbar, die mit verschiedenen Clients kompatibel ist. SapphireDb ermöglicht es Anwendungen mit Echtzeit-Daten-Synchronisation zu erstellen. Mehr Informationen unter: https://sapphire-db.com/

register now

Registrieren Sie sich für unseren Newsletter und erhalten Sie regelmäßig Informationen zur iterate=>RUHR Konferenz. Wir werden Sie regelmäßig über die Sessions, Workshops, Speaker, Ticketpreise und die wichtigsten Termine rund um die Konferenz informieren.