Christian Seifert ist Software Engineer mit fast 20 Jahren Erfahrung in der Entwicklung und dem Support von Individualsoftware. Ob beim Schreiben von Code, der Analyse von Anforderungen oder dem Mentoring im Team – für ihn geht es immer darum genau die Lösung zu finden, die auch tatsächlich von Anwendern benötigt wird und gewollt ist. Auch wenn ihn ursprünglich die Faszination an der Technik zur Softwareentwicklung trieb so verbringt er heute mindestens genauso viel Zeit mit Menschen und wirbt leidenschaftlich für ein besseres Verständnis zwischen Entwicklungsteams und Business Stakeholdern. Aktuell ist er Senior System Architect bei BetterDoc und hilft dabei die richtigen Ärzte mit Patienten zusammen zu bringen, die ihre Expertise benötigen. Bei schönem Wetter trifft man ihm beim Joggen im Park oder auf dem Fahrrad. Bei schlechtem Wetter eher auf der Couch, wo er vergeblich versucht seinen Netflix-Konsum unter Kontrolle zu halten.
“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.
Lena Groß ist BI-Beraterin und Clean Code-Enthusiastin bei der viadee. Ihre Schwerpunkt-Themen sind Anforderungsanalyse, Datenmodellierung und Software-Entwicklung in Data-Warehouse- und Java-Projekten.
(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!
Schon während des Studiums hat Alexandra Windisch bei IBM EDV-Kurse für AS/400 und Lotus Notes gehalten. Mehr als 15 Jahre war sie dann in internationalen Projekten tätig, davon 10 Jahre im Projektmanagement und als Scrum Master/Teamleiterin von virtuellen, agilen Teams. Bei adesso ist Alexandra als Senior Consultant und glühende Agilistin hauptsächlich in agilen Projekten als PO oder Scrum Master tätig, schult, coached und berät Kunden und KollegInnen und verantwortet in Österreich den Themenschwerpunkt DSGVO und Agilität.
Kurze Zusammenfassung agiler Vorgehensweisen und Spiele zum interaktiven Erleben
Ein eingespieltes Team für ein paar Wochen ins homeoffice zu schicken kann problemlos funktionieren, wenn
Hier gebe ich ein paar Tipps, wie das gut gelingen kann.
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
Karl-Heinz ist Softwareentwickler, Build- und Konfigurationsmanager im Bereich Java, JEE sowie Trainer (Maven, Git, Jenkins, Subversion, Nexus), Apache Maven PMC Mitglied und MojoHaus Committer.
Im Dezember 2000 wurde der erste Commit für JUnit 3 gemacht. Im Februar 2006 erblickte JUnit 4.0 die Welt. Im Februar 2016 schließlich erblickte die Alpha Release von JUnit Jupiter das Universum. Im Java Universum sind einige wenige Testframeworks verbreitet. Dazu zählt z.B. das JUnit Framework oder TestNG usw. Die entsprechenden Testframeworks erleichtern die Implementierung von Unit- und/oder Integrationstests.
Ich möchte im Rahmen des Vortrages zeigen, welche Änderungen sich aus der Nutzung von JUnit Jupiter im Vergleich zu anderen Frameworks/Versionen ergeben. Dazu zählen beispielsweise die Unterschiede in den Annotationen sowie deren Auswirkungen, Verwendung von Test Klassen und die Unterstützung für das Testen von Interfaces.
Es gibt auch oft Anforderungen, Tests mit unterschiedlichen Daten auszuführen sog. parametrisierte Tests eventuell auch noch von unterschiedlichsten Quellen oder einfach Tests mehrfach zu wiederholen. Das Ganze wird noch ergänzt mit Hinweisen bzgl. der Migration von JUnit3/4/TestNG Tests auf JUnit Jupiter.
Andere Punkte sind beispielsweise noch die Verwendung von dynamischen Tests.
Im Rahmen des Vortrages möchte ich zeigen, wie beispielsweise Spring, Quarkus, Testcontainers etc. die Unterstützung für das Testen so einfach gemacht haben.
In den eigenen Projekten wird man oft mit Anforderungen konfrontiert, einen End-To-End Test zu erstellen. Das führt aber häufiger zu Kombinationen aus Shell Scripten o. ä. und/oder Java Code. Das Problem dabei ist aber, dass hier dann die Zusammenarbeit/Wartbarkeit recht schwierig ist. Hier bietet JUnit Jupiter den Extension Mechanismus an mit dem solche Themen elegant lösbar sind.
Ziel ist es hier, die Erweiterungsmöglichkeiten von JUnit Jupiter zu zeigen und darzulegen wie man das in der Entwicklung gezielt einsetzen kann.
Marco Emrich ist Senior Consultant bei codecentric und leidenschaftlicher Verfechter von Software Craft und Codequalität. Er hält regelmäßig Vorträge auf bekannten Konferenzen und ist Autor mehrerer Fachbücher. Wenn Marco nicht gerade Entwicklertreffen organisiert, erklärt er seinem Sohn wahrscheinlich gerade, wie man Roboterschildkröten programmiert.
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.
Judith Strunk ist seit 4 Jahren User Experience Engineer bei der Firma PROSOZ Herten GmbH. Sie ist sowohl in der Produktentwicklung unterwegs, als auch für Schulungen, um die Methoden des User Experience Design im Unternehmen zu verbreiten. Mit ihrem Hintergrund als Sozialpsychologin nutzt sie Methoden und Wissen aus der Psychologie, um neue Produkte zu gestalten und den tatsächlichen Anforderungen der Anwender auf den Grund zu gehen.
„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.
Ursula Krischik arbeitet seit mehr als 20 Jahren in der Software-Entwicklung in Projekten unterschiedlicher Größenordnung. Ursula Krischik findet es wichtig, wenn das Teamwissen auf einen Level gehoben wird und die gemeinsame Arbeit zu guten Ergebnissen führt.
“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.
Als Gründer der bee42, CTO, Systemarchitekt, Digtial Native, Apache-Member, Apache Tomcat Committer, Infracoder und DevOps Influencer bringt Peter seine bemerkenswerte IT- und Organisationserfahrung ein. Mit seinen Fähigkeiten inspiriert er Communities, Partner und Kunden. Seine Ziele sind es lebenslanges Lernen zu fördern und sinnstiftende digitale Services zu gestalten. Einfach gesprochen, Chancen zu ergreifen und achtsam mit der Veränderung umzugehen.
Stefan beschäftigt sich seit Jahren mit dem Thema Clean Code und habe gewisse Freiheiten, im Team dieses voranzutreiben. Das heißt, er ist der Multiplikator, der mittels Vortragen und Vorleben die Kollegen sensibilisieren soll.
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…
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.
André Claaßen ist Agile Business Coach aus Leidenschaft. Der studierte Informatiker hat mehr als 30 Jahre Erfahrung in der Software-Entwicklung und IT-Projekten aller Größenordnungen. In den letzten Jahren spezialisierte er sich in den Themenfeldern Agile Leadership und der digitalen Transformation von Organisationen. André Claaßen sieht in der Digitalisierung nicht nur ein technisches, sondern auch ein gesellschaftliches Thema und eine Chance für mehr Kooperation, Zusammenarbeit und Vernetzung.
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.
Juliana Stepanova discovered the agile world end of 2016 and since that time she works as an agile coach in IT companies. The focus of her work is to coach co-located/distributed teams in national and international organizations in better performing via applying agile techniques, regularly reflect on the way of working, and respectively improving processes. She has a lot of energy and spreads it to colleagues, friends, and family encouraging people to explore their horizons. Juliana finds personal growth crucial for her and combining learning and coaching she stands to develop herself and others. She is eager for experiments and metrics and she never stopping producing new ideas and trying new things.
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.
Slawa Gladkow is a Software Engineer with 10+ years of experience working on anything from computational material science and high-performance computing to modern web development. His main professional interests are hexagonal architectures, clean code, microservices, test-driven development and message-driven systems. Currently, Slawa is involved in digitalising the area of non-destructive testing (NDT) working on Drive NDT – all-in-one cloud-based solution to manage NDT workflows.
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.
Sven Ruppert arbeitet als Fellow bei der Reply Group in München, spricht seit 1996 Java und arbeitet seitdem in nationalen und internationalen Projekten. In seiner Freizeit schreibt er als Gastautor für JAXenter (http://jaxenter.de/Sven-Ruppert-168244), http://www.rapidpm.org sowie im Java, Entwickler und Eclipse Magazin. Am liebsten hält er in Deutschland bei JUGs Vorträge.
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.
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.
Katharina Warak arbeitet als agile Testerin bei der Carl Zeiss Digital Innovation GmbH und ist für die Qualitätssicherung innerhalb der Projekte im agilen Umfeld tätig. Sie ist verantwortlich für die Automatisierung auf API- und GUI-Ebene. Zu den Leidenschaften von Katharina Warak zählt es, den Kunden und Projekten, durch die Nutzung von kollaborativen Testmethoden, neue Perspektiven aufzuzeigen und diese Methoden zur Verbesserung der Arbeitsweisen im Team einzusetzen
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.
Sebastian Kleinschmager ist freiberuflicher Softwareentwickler, Berater und Trainer. Mit dem Ruhrpott als Wahlheimat trägt er das Herz auf der Zunge, ist dabei aber immer mit einem Lächeln und einer gehörigen Portion Selbstironie unterwegs. Er leitet die Microsoft Developer Usergroup in Essen und ist unter anderem Teil des IT-Vision Expertennetzwerks. In seiner Freizeit macht er viel Musik, betätigt sich sportlich und pflegt natürlich das eine oder andere Nerd-Hobby.
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.
Morris beschäftigt sich mit Themen rund um die Entwicklung und Bereitstellung von Cloud basierten Anwendungen. Er setzt sich für die Entwicklung von Quelloffenen Lösungen ein und versucht so einen Beitrag in der nicht proprietären Softwareentwicklung zu leisten.
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/
Diplom-Wirtschaftsinformatiker Christoph Meyer ist Senior Berater und Softwarearchitekt bei der viadee IT-Unternehmensberatung und seit 2006 in Kundenprojekten im Bereich Handel, Banken und Versicherungen unterwegs. Er ist Clean Code Evangelist und Kanban-Fan und hat mit den Schwerpunkten Backend-Security, Batchverarbeitung vom Host bis Spring und DevOps immer neue Seiten seiner Java-Leidenschaft entdeckt. Bewältigung von Legacy-Software mit Herstellung von Testbarkeit und großen Refactorings findet er spannend. Christoph gibt sein Wissen gerne in Workshops an Kunden, Kollegen und Studenten weiter.
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“.
Björn Meschede ist Senior Berater bei der viadee IT-Unternehmensberatung. Als Software Engineer und Projektleiter hat er die Herausforderung, Clean Code nicht nur bei der Neuentwicklung, sondern auch in der Wartung zu schreiben, von beiden Seiten der Medaille kennen gelernt. Er ist bei der viadee u.a. Serious Games Facilitator, Workshop-Moderator und Teil des Clean Code Teams.
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.
Inna Yakovenko focuses on how to improve software development processes and team collaboration since 2016 in different roles as a scrum master, requirements management, and product owner.
Over the years she discovered different tools, techniques, and approaches to measure and increase the team’s performance. She runs her experiments and uses each possibility to learn from her own and others’ experiences.
Inna is a huge fan of solution-focused coaching and always tries to bring teams to the next level. She also supports other people to develop a growth mindset and helps them to apply the inspect and adapt principle.
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.
Nach seinem Diplom in angewandter Informatik an der TU Dortmund arbeitete Andrej Thiele als Software Entwickler in verschiedenen Bereichen der Industrie, wie z.B. Digitalisierung von Radios, Telekommunikation, Mobilfunk und eingebettete Systeme. Im Jahr 2008 stieg er in die IT-Beratung ein und unterstützte diverse Firmen im Bereich Entwicklung, Architektur und Testen. Dabei entwickelte er eine starke Affinität zur Qualität der von ihm entwickelten Software und zur hoher Qualität des Quellcodes. Er erweitert kontinuierlich sein Wissen und seine Fähigkeiten in der Testgetriebenen Entwicklung, Test-Automation und im DevOps und nutzt dieses Wissen in seiner täglichen Arbeit. Seit 2016 arbeitet er als Senior Consultant bei der Conciso GmbH in Dortmund, wo er regelmäßig das Conciso Coding Dojo Dortmund veranstaltet und die Testgetriebene Entwicklung mit interessierten Teilnehmern übt. Zusätzlich ist er Trainer der Agile Testing Fellowship für den Kurs “The Whole Team Approach for Agile Testing”.
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.
Martin Hüser ist Informatiker und Software Engineer mit mehr als 20 Jahren Erfahrung in der Softwareentwicklung, Schwerpunkt Kommunikationssoftware. Seine aktuellen beruflichen Hauptinteressen sind Software-Architektur in einem agilen Umfeld, Clean Code, DevOps. Zur Zeit ist er Softwarearchitekt bei Swyx Solutions GmbH.
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.
Benedikt Wörner ist seit 12 Jahren im Bereich Test und Qualitätsmanagement unterwegs. Viele Jahreleitete er Testteams in unterschiedlichen Branchen und vermittelte sein Wissen als Coach in diversen Schulungen. Heute arbeitet Benedikt Wörner als Gruppenleiter QA sowie Senior Consultant bei der Carl Zeiss Digital Innovation GmbH. Seine Leidenschaft ist es, Kunden bei der agilen Transformation zu helfen. Er eröffnet den Kunden neue Wege und Perspektiven, z.B. anhand kollaborativer Testmethoden sowie spannenden Workshopformaten.
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.
Kartik Adur is a Web Developer with an interest in Research, Development, and Design. He has a Masters in Information Science and work experience in Frontend Development. When he’s not stuck behind a computer he likes exploring outdoors. When he is stuck behind a computer he’s looking to learn how to make beautiful UI.
Thomas arbeitet als IT-Consultant bei der codecentric AG. Er ist überzeugt von dem Erfolg Agiler Softwareentwicklung und von entsprechenden Methoden und Praktiken. Thomas setzt sich für sauberen Code ein und dafür, dass das Testen im Projekt nicht zu kurz kommt. Als Co-Organisator der Softwerkskammer Ruhrgebiet unterstützt er den Austausch, das Lernen und das Üben in der Entwickler-Community.
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.
Gerrit Beine ist Senior Manager bei der DARCBLUE AG und seit 1998 in der IT unterwegs, seit 2001 mit agilen Methoden. Er war viele Jahre lang Software-Architekt in großen Projekten. In den letzten 10 Jahren baut er immer wieder Brücken zwischen agilen Organisationen und langlebigen Software-Architekturen.
Gerrit hat Informatik studiert und hat einen MBA in General Management. Er ist Autor zahlreicher Fachartikel und regelmäßig als Sprecher auf Konferenzen zu den Themen Software-Architektur und Agile zu treffen.
.
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.
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.
Anika Zohren ist Software Entwicklerin seit 2002 – Schwerpunkte sind Java, SAP commerce (aka hybris) und statische Quelltext Analyse.
“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?
Andreas Richter ist seit vielen Jahren leidenschaftlicher Softwarecraftsman und Architekt. Über die Jahre hat er durch die Arbeit an unterschiedlich großen Projekten mit einer Vielzahl an Plattformen, Frameworks und Programmiersprachen ein ausgeprägtes Verständnis für sauberen Code, gutes Design und effektive Architekturen entwickelt.
Aktuell liegt sein Schwerpunkt auf dem .NET Framework mit C# und diversen Bibliotheken aus diesem Umfeld. Neben klassischen Desktop-Anwendungen entwickelt er auch Mobile- und Web-Anwendungen u.a. mit Xamarin. Dabei kommt bereits seit einigen Jahren das arc42 Template für die begleitende Architekturdokumentation zum Einsatz. Aktuell ist er bei der advanto Software GmbH in Magdeburg als Softwareentwickler und Architekt tätig und betreut dort mit seinen Kollegen hochwertige Software für den Einsatz im Finanzsektor.
Softwareentwicklung ist für ihn keine reine Produktion von Code sondern vielmehr eine Profession und eine Handwerkskunst. Um dem Anspruch gerecht zu werden, ist lebenslanges Lernen, stetiger Wissensaustausch und häufiges Üben essentiell. Aus diesem Grunde besucht er Konferenzen, bildet sich in Workshops weiter und nimmt aktiv als Gast, Redner und Workshopleiter an Communityveranstaltungen wie den [Magdeburger Developer Days](https://md-devdays.de/), der [Spartakiade](https://spartakiade.org/) und dem [Developer Open Space](https://devopenspace.de/) teil. Weiterhin leitet er seit September 2013 erfolgreich die [Softwerkskammer in Magdeburg](https://www.softwerkskammer.org/groups/magdeburg).
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.
Johannes Dienst ist Diplom Informatiker und Softwarecrafter mit 8 Jahren Berufserfahrung in der Entwicklung von komplexen IT-Systemen im Umfeld von Java, JavaScript und allen möglichen anderen Sprachen. Seine sonstigen Interessen sind breit gestreut mit Fokus auf Softwarequalität und Softwarearchitektur. Sein Wissen teilt und erweitert er gerne als Sprecher auf Konferenzen und mit Fachartikeln. In seiner Freizeit gehört sein Herz der Familie für die er sich mit Kraftsport fit hält.
