Bi-temporale Events haben nicht nur ein einzelnes Datum (z. B. das Datum, wann das Event aufgetreten ist), sondern zwei Daten (z. B. das Datum des Auftretens und wann es sich auswirkt). So mache ich beispielsweise heute eine Überweisung, welche Ende Monat ausgeführt wird.

Im Gegensatz zu normalen Events, müssen bei der Projektion von bi-temporalen Events und bei deren Read Models einige zusätzliche Dinge berücksichtigt werden: Ordnung der Events nach zwei Dimensionen, Bedeutung eines früheren effektiven Datums (Überschreibend, Einfügend) usw.

In dieser Präsentation zeige ich euch nach einer kurzen Einführung in «normales» Event-Sourcing die Konzepte und Implementationen, welche wir in unserer Zeiterfassungssoftware einsetzen, um die Möglichkeiten von bi-temporalen Daten zu nutzen. Ich zeige euch die Projektoren für einfache Werte und für Timelines, um einfach auf historische Daten zugreifen zu können; sowie für mengenbasierte Werte und Werte mit einem Lebenszyklus.

F# ist einer der drei .NET-Sprachen und meine Lieblingsprogrammiersprache. F# legt mehr Gewicht auf Konzepte aus der funktionalen Programmierung als C# und VB.NET. Leider merke ich immer wieder, dass einige Mythen über F# weit verbreitet sind – wie zum Beispiel:

- F# = Funktionale Programmierung und C# = Objekt Orientierte Programmierung
- F# taugt nur für mathematische Berechnungen
- F# ist viel schwieriger zu erlernen als C# oder VB.NET
- in Kürze kann C# eh alles, was F# zu bieten hat
- in F# hat es viel mehr Operatoren als in C#
- C# hat das bessere Tooling
- F# ist langsam
- Imperative und objektorientierte Programmierung ist einfacher als funktionale

Höchste Zeit sich diese Mythen genau anzuschauen und herauszufinden, ob sie wahr oder falsch sind.

Collective Product Ownership bedeutet, dass alle Mitglieder des Produktsteams bei der Gestaltung des Produkts Einfluss nehmen können.

Dies führt neben einer gestärkten Identifizierung mit dem Produkt zu mehr Motivation, diverseren Produktentscheidungen, mehr Effizienz und weniger Risiko als zum Beispiel das Delegieren dieser Aufgabe an einen einzelnen Product Owner.

Im Workshop betrachten wir, welche Herausforderungen beim Wechsel zu Collective Product Ownership bestehen, wie wir diese meistern und welche Effekte daraus resultieren. Einer dieser Effekte ist, dass sich das Team als Ganzes in der Domäne, in der es sich bewegt, entwickelt in dem es die zu lösenden Probleme aus erster Hand kennt und so effizienter zu effektiven Lösungen beitragen kann.

Das Manifest der agilen Softwareentwicklung sagt, wir sollen bessere Wege erschließen, um Software zu entwickeln. Wir haben Scrum hinter uns gelassen, weil wir schneller lernten als der Sprint lang war und der Sprint uns mehr blockierte als unterstützte. Besser passt uns die Trennung der Zyklen für Planung, Retrospektive, Auslieferung und Feedback. Und dass sich jedes Teammitglied von Anfang bis Ende einbringen kann, hat die Motivation im Team stark erhöht.

Dies ist das Caretaker-Model.

Blog post

Bi-temporale Events haben nicht nur ein einzelnes Datum (z.B. das Datum, wann das Event aufgetreten ist), sondern zwei Daten (z.B. das Datum des Auftretens und wann es sich auswirkt). So mache ich beispielsweise heute eine Überweisung, welche Ende Monat ausgeführt wird.

Im Gegensatz zu normalen Events, müssen bei der Projektion von bi-temporalen Events und bei deren Read-Models einige zusätzliche Dinge berücksichtigt werden: Ordnung der Events nach zwei Dimensionen, Bedeutung eines früheren effektiven Datums (Überschreibend, Einfügend) usw. In dieser Präsentation zeigt Urs euch nach einer kurzen Einführung in «normales» Event-Sourcing, die Konzepte und Implementationen, welche wir in unserer Zeiterfassungssoftware einsetzen, um die Möglichkeiten von bi-temporalen Daten zu nutzen. Urs zeigt euch die Projektoren für einfache Werte und für Timelines, um einfach auf historische Daten zugreifen zu können; sowie für Mengen-basierte Werte und Werte mit einem Lebenszyklus.

Modern programming languages support both object-oriented and functional programming to a large extent. What are the differences between the two approaches and where is one more appropriate than the other? Can these two programming paradigms be combined?

In this session, we look at the differences and similarities between functional and object-oriented programming using examples in C# and F#.

If we start with the architecture of new software, we must think about many things. I use a list of 23 architectural aspects, like persistence, communication, translations, archiving, scaling, Security, Exception handling etc., to guide my design.

By taking an evolutionary approach, we can tackle these aspects incrementally and allow us to learn a lot about the problem to be solved and possible solutions before deciding. Instead of a big-design-up-front based on many assumptions, we create options among which we can choose the optimal one as late as possible.

After this presentation, you will know the architectural aspects that are important when working on architecture and how to implement them in many small steps.

Wenn wir mit der Architektur einer neuen Software starten, dann müssen wir an vieles denken. Unter anderem an 23 Architekturaspekte, wie Persistenz, Übersetzungen, Archivierung, Skalierung, Security, Exception Handling usw.

Durch eine evolutionäre Herangehensweise können wir diese Aspekte schrittweise angehen und ermöglichen es uns, zuerst viel über das zu lösende Problem und mögliche Lösungen zu lernen, bevor wir entscheiden müssen. Statt eines Big-Design-Up-Front auf Basis vieler Annahmen, schaffen wir uns Optionen unter welchen wir möglichst spät die optimale auswählen können.

Nach dieser Präsentation kennt ihr die Architekturaspekte, welche mir wichtig sind beim Arbeiten an der Architektur und wie diese in vielen kleinen Schritten umgesetzt werden können.

Diskussion von Simon Martinelli und Urs Enzler:

• Modellierung von Daten anhand des Businessprozesses oder des Verhaltens
• Daten sind wichtiger als langlebiger Code
• Migration von Daten um diese den sich ändernden Prozessen und Verhalten anzupassen
• Datenbankzugriff: aus Daten generieren oder Code-first?

Schätzen funktioniert nicht - auch nicht, wenn wir mehr Aufwand in die Schätzung stecken.

In dieser Präsentation zeige ich euch, warum das so ist und was wir stattdessen tun sollten.

Nach dem Vortrag wisst ihr mehr über komplexe Systeme, wo der Aufwand in der Softwareentwicklung wirklich steckt, welche Ursachen Verzögerungen haben, warum Kommunikation eines der Hauptprobleme ist und warum bei Software eine Diseconomy of Scale gilt.

The architecture of modern software systems has to adapt to changing user needs and technological innovation continuously. Simplicity is the essential factor to support the evolution of software architecture.

In this presentation, I'll show you a model that helps reflect on the simplicity of the architecture and practices that support keeping the architecture as simple as possible - like continuous refactoring, decision-decomposition, and concrete-specific instead of abstract-generic designs.

Moderne Programmiersprachen unterstützen sowohl objektorientierte als auch funktionale Programmierung in grossen Teilen.

Doch was sind die Unterschiede der beiden Ansätze und wo eignet sich der eine besser als der andere? Oder lassen sich die beiden Programmierparadigmen sogar kombinieren?

In dieser Session schauen wir uns die Unterschiede und Gemeinsamkeiten am Beispiel von C# und F# Code an.

Das Manifest der agilen Softwareentwicklung sagt uns, wir sollen bessere Wege erschließen, um Software zu entwickeln.

Wir haben Scrum hinter uns gelassen, weil wir unter anderem schneller dazu gelernt haben als der Sprint lang war und der Sprint uns mehr blockiert als unterstützt hat. Scrum fühlte sich für uns zu langsam und zu unflexibel an.

Stattdessen haben wir eine Arbeitsweise gefunden, welche uns besser unterstützt, durch Trennung der Zyklen für Planung, Verbesserung, Retrospektiven, Auslieferung und Feedback. Und die Möglichkeit, dass sich jedes Teammitglied von Anfang bis Ende einbringen kann, hat die Motivation im Team stark erhöht. Dies ist das Caretaker-Modell.

In dieser Präsentation erkläre ich euch, wie das Caretaker-Modell funktioniert, warum das Caretaker-Modell viel besser zu uns passt und zu dir und deinem Team möglicherweise auch.

Wir treffen jeden Tag unzählige Entscheide: Kleine (mach ich da nun einen Zeilenumbruch?), mittlere (welche Lösungsvariante setzen wir um?) bis grosse (bauen wir dieses Produkt?). Doch wie machen wir das überhaupt? Eher zufällig oder strikt nach Prozess? Alleine oder im Team? Und was wenn wir uns nicht einig werden? In dieser Session tauschen wir uns darüber aus, was wir wie und wann entscheiden und finden bessere Wege für bessere Entscheide.

Wir werden unter anderen folgende Themen betrachten:

• Vorbereiten von Entscheidungen
• Auswahl der Entscheidungsmethode basierend auf der Art der Entscheidung und Kriterien für Beurteilung der Art der Entscheidung
• Kommunizieren und Dokumentieren von Entscheidungen
• Entscheidungen rückblickend validieren

Die Ära der Projekte in der Softwareentwicklung ist vorbei. Mit Projekten ist es nicht mehr möglich, die heutige IT-Welt in den Griff zu bekommen. Komplexe Zusammenhänge zwischen Stakeholdern und Umsystemen sowie rasant ändernde Technologien sind nicht mehr beherrschbar.

Das Resultat: zu teuer, zu spät, am Problem vorbei entwickelt.

Statt in Projekten zu denken, müssen wir uns auf den Produkt-Lebenszyklus ausrichten: Geburt, Weiterentwicklung, Ablösung.

Ein Denkanstoss für neue Wege in der Softwarenentwicklung.

Those who develop with .NET probably do so with C#. But F#, in particular, has great potential to make daily work easier. Everything that C# can do can also be done with F#, and often in a more lightweight and less error-prone way. If you want to see where the differences are and why F# is a good programming language for normal software development, come to this session! And don't worry, the talk is free of functional programming jargon – I promise!

Die Architektur von modernen Softwaresystemen muss sich ständig anpassen an geänderte Benutzerbedürfnisse, Technologieänderungen und neue technische Möglichkeiten. Einfachheit – Simplicity – ist bei weitem der wichtigste Faktor, um die Evolution der Softwarearchitektur zu unterstützen. In diesem Vortrag zeige ich euch ein Modell, um über Architektureinfachheit zu reflektieren und mehrere Techniken, um die Softwarearchitektur so simpel wie möglich zu gestalten.

Wer mit .NET entwickelt, macht das wahrscheinlich mit C#. Doch gerade F# hat großes Potenzial, die tägliche Arbeit zu erleichtern. Denn alles, was C# kann, geht auch mit F#, und das oft leichtgewichtiger und weniger fehleranfällig. Möchtest du sehen, wo die Unterschiede liegen und warum F# eine gute Programmiersprache für ganz normale Softwareentwicklung ist, dann komm in diese Session! Und keine Angst, der Vortrag ist frei von Functional-Programming-Fachchinesisch – versprochen!

Statt langwierige Analyse, Planung und Ausführen, heisst es Hypothese, Experiment und Verifikation in kurzen Zyklen.

Das Manifest der agilen Softwareentwicklung sagt uns, wir sollen bessere Wege erschließen, um Software zu entwickeln. Das Caretaker-Modell beschreibt die Art, wie mein Team arbeitet. In dieser Präsentation erkläre ich euch, warum wir Scrum hinter uns gelassen haben und unsere eigene Methode adoptiert haben. Und natürlich, warum das Caretaker-Modell viel besser zu uns passt, und zu dir und deinem Team möglicherweise auch.

Architektur steht für Stabilität und weitreichende Entscheide. Und das soll in einem schnelllebigen, flexiblen Agilen Projekt möglich sein? Urs Enzler zeigt in dieser Präsentation, wie sich Architektur mit den User Stories zusammen evolutionär entwickeln kann, wie Entscheide bis zum richtigen Zeitpunkt vertagt werden können und welche agilen Architekturmuster es gibt. Ihr lernt, wie eine agile Architektur schnelle Änderungen, einfache Architekturvalidierung und ein immer lauffähiges System ermöglicht.

Wir treffen jeden Tag unzählige Entscheide: Kleine (mach ich da nun einen Zeilenumbruch?), mittlere (welche Lösungsvariante setzen wir um?) bis grosse (bauen wir dieses Produkt?). Doch wie machen wir das überhaupt? Eher zufällig oder strikt nach Prozess? Alleine oder im Team? Und was wenn wir uns nicht einig werden? In dieser Session tauschen wir uns darüber aus, was wir wie und wann entscheiden und finden bessere Wege für bessere Entscheide.

In meiner Zeit als Softwareentwickler gab es immer wieder Aha-Momente, welche die Art und Weise verändert haben, wie ich Software entwerfe: - Inversion-of-Control-Container machen alles unnötig kompliziert. - OR-Mapper sind nur Pseudoabstraktionen. - Faking-/Mocking-Frameworks sind der Tot von guten Unit-Tests. - Softwarearchitekturdokumente sind Zeitverschwendung. Ich zeige euch, mit welchen Konzepten und Methoden wir aktuell arbeiten und ein einfacheres Softwaredesign erreicht haben. Und ich wage eine Prophezeiung, was meine nächsten Lernschritte sein werden. Schärft mit mir euren Blick auf Designentscheide.

Jeder Softwareentwickler löst täglich viele kleine und grosse Probleme, zum Beispiel Architektur-, Design- oder Technologieprobleme. Während die kleinen Probleme schnell behoben sind, ist bei grösseren Problemen oft die Gefahr, einfach die erstbeste Idee umzusetzen. In diesem Workshop zeige ich auf, wie schwierige Probleme mit einer geordneten Problemlösung einfacher lösbar sind und langfristig zu besseren Ergebnissen führen. Am Beispiel eines realen Projekts (anonymisiert) üben wir das Problemlösen. Wir befassen uns mit den folgenden Themen: - Eigenschaften von schwierigen Probleme - Schwierigkeiten mit der Lösungsfindung - Problemverständnis fördern - Alternativen erarbeiten und bewerten - Entscheidungsfindung - Umsetzung in evolutionären Schritten - Retrospektive und Lessons Learned

Vielleicht kennt ihr die Testpyramide mit Unit-, Integrations- und UI-Test. Um wirklich flexible, erweiter- und veränderbare Software zu schreiben, ist die Testpyramide aber eine zu grobe Beschreibung und eine schwierig umzusetzende Anleitung. Ich zeige euch in dieser Session, wie wir unsere Software testen und vor allem, warum wir wann welche Art von Tests verwenden. Agiles Testen unterstützt die Agilität und behindert sie nicht. Lernt von meinen Fehlern, Erfolgen und Erfahrungen, die ich in meinen Projekten gemacht habe.

Heute entwickeln ja alle ihre Software agil - so mehr oder weniger. Doch agil ist mehr als jeden Tag zusammen stehen, ein paar Meetings alle 2 Wochen und ein Backlog in TFS. Agil Software zu bauen bedeutet in erster Linie auf den Menschen zu fokussieren und die Kollaboration und Team-Autonomie zu stärken. Agil zu sein heisst, der Komplexität heutiger Software mit den richtigen Werkzeugen zu begegnen. Nach dieser Session weisst du, was "agile Softwareentwicklung" wirklich ist. Wir sprechen über Komplexität, Kollaboration, Team-Autonomie, kontinuierliche Verbesserung, schnelles Feedback und die Fähigkeit auf Feedback überhaupt reagieren zu können. Und damit du selber etwas ändern kannst, erfährst du konkrete Tipps und Tricks, wie du dein Team agiler machen kannst.

Agile Softwareentwicklung ist mehr als täglich zusammen zu stehen und alle 2 Wochen den Stakeholdern den Fortschritt zu zeigen. Wenn die agilen Werte auf das Requirements Engineering angewendet werden, bleibt kaum ein Stein auf dem anderen bezüglich der herkömmlichen Arbeitsweise. In diesem Vortrag präsentiere ich meine Top 5 Punkte des agilen Requirements Engineering: - Inkrementelles und iteratives RE statt langwieriges Requirements-Gold-Plating - Specification by Example mit automatisierten Akzeptanztests statt dicke Pflichtenhefte mit Widersprüchen - Problemzentrierte Anforderungen statt Pseudo-Lösungen - Requirements Engineering im Team statt Einzelkämpfer und Missverständnisse - Priorisieren und Übersicht halten statt alles-ist-wichtig Lernen Sie von meinen Erfahrung aus der Arbeit in und mit agilen Teams.

Die meisten Teams machen Scrum, weil es heutzutage quasi der Standard ist für die agile Softwareentwicklung. Jedoch begnügen sich viele dieser Teams damit Scrum by the book abzuspulen, ohne verstanden zu haben, worum es bei agiler Softwareentwicklung wirklich geht. In diesem Beitrag präsentiere ich die Missverständnisse, denen ich beim Coaching von Teams immer wieder begegne.

Wir alle wissen, dass wir unsere Software modular aufbauen sollten. Wir lesen das in Büchern, hören es in Vorträgen und von unseren Kollegen. Doch wenn wir ehrlich sind, haben wir grosse Mühe damit. Wie gross soll ein Modul sein, was genau gehört da rein, wie greifen wir darauf zu, wie Bauen wir die Software aus den Modulen zusammen? Über diese Fragen möchte ich mit euch diskutieren. Ich zeige euch, wie wir unsere Software in Module zerlegt haben und wie diese miteinander interagieren. An realem Source Code seht ihr, wie wir Module schneiden, Interfaces designen, die Module zu einem ganzen Integrieren, die Software testen und mit all dem ein agiles Vorgehen ermöglichen.

Architektur steht für Stabilität und weitreichende Entscheide. Und das soll in einem schnelllebigen, flexiblen Agilen Projekt möglich sein? Ich zeige in dieser Präsentation wie sich Architektur mit den User Stories zusammen entwickeln kann, wie Entscheide bis zum richtigen Zeitpunkt vertagt werden können und welche agilen Architekturmuster es gibt. Ihr lernt, wie eine Agile Architektur schnelle Änderungen, einfache Architekturvalidierung und ein immer lauffähiges System ermöglicht.

Refactoring is not just for cleaning up after adding a new feature. Refactoring works anytime! Both when I stumble over an ugly piece of code, and before implementing a new feature to ease the addition. After this session, you'll know when and how refactoring can be applied successfully. This way, coding your software will still be fun tomorrow! I'll show different workflows and patterns for refactoring at different points in time when developing software: Before, during and after adding new features, while reading and understanding existing code, and when cleaning up a big mess.

Zu Beginn in einem neuen agilen Team ist die Euphorie gross. Schliesslich verspricht die agile Vorgehensweise riesige Produktivitätsgewinne, mehr Spass bei der Arbeit und dass der Kunde genau das kriegt, was er braucht. Nur ist der Weg dahin sehr steinig und viele Teams kommen vom Weg ab oder bleiben stecken. Ich zeige euch in dieser Präsentation, welche Meilensteine ein agiles Team auf seinem Weg zur Agilität durchläuft und welche Hindernisse im Weg liegen und wie diese überwunden werden. Eine Reise zu Teambildung, Kollaboration, stetigem Lernen, schnellem Feedback und dem agilen Mindset.

Warum ist das eigentlich bei der Softwareentwicklung nicht möglich? Oft verhindern das schon banale Gründe: Der Sourcecode ist häufig in einem Zustand, der zunächst ein aufwendiges und zeitintensives Refactoring verlangt, bevor neue Funktionalität hinzugefügt werden kann. Dann folgt eine langwierige Testphase, um sicherzustellen, dass keine Fehler eingebaut wurden. Und schließlich dauert es lange, bis das Release erstellt und ausgeliefert ist. Wäre es nicht besser, wenn wir uns auf das Wesentliche konzentrieren könnten und die Herausforderungen, die der Kunde uns stellt, zu verstehen und zu beherrschen? In dieser Session zeige ich Ihnen, wie die Infrastruktur unserer Projekte aussieht, damit wir schnell und mit hoher Qualität die von unseren Kunden gewünschten Ziele erreichen können. Erfahren Sie, wie wir unsere Tool-Chain von der Versionskontrolle über Build-Automatisierung bis zu Continuous Deployment verwenden, um uns schneller und leichter auf die gestellte Aufgabe konzentrieren zu können.

Die Software muss schnell sein, schön aussehen, stabil und einfach zu bedienen sein. Alles wichtige Qualitätsaspekte. Alles Dinge, welche ein Benutzer wichtig findet. Darum schreiben wir Software, die dies alles erfüllt. Doch all zu oft schleicht sich langsam aber sicher ein Monster unter die schöne Hülle unserer Software ein. Ein Monster, welches beginnt, sämtliche Motivation und Innovation im Entwicklungsteam aufzufressen. Ein Monster, welches Entwickler bis zum Teamwechsel bringt, weil dessen Präsenz nicht mehr aushaltbar ist. Ein Monster, das Produkte von innen tötet, weil irgendwann auch die schöne Hülle zu zerbrechen beginnt. Dieses Monster ist bekannt unter verschiedenen Namen: technische Schuld, Big Ball of Mud oder Spaghetticode. Darum denken wir jetzt mal an uns Entwickler und bauen Software, in der wir uns wohl fühlen. Und somit die Langlebigkeit der Software ermöglichen. Eine Session rund um Cleancode, Clean-Architecture, Softwareevolution und ja, auch Testing.

Mit Acceptance Test Driven Development (ATDD) haben wir Entwickler ein Werkzeug in der Hand um die Kommunikation mit unseren Stakeholdern zu verbessern. Dies reduziert Missverständnisse und lässt Entwickler fokussierter Arbeiten. Aber das ist noch lange nicht alles, dazu gibt es automatische Regressionstests, ausführbare Spezifikationen und ein gutes Gewissen, dass die Software läuft. Und das alles in der Hälfte der Zeit! Klingt zu gut um wahr zu sein, ist aber so. Ich zeige euch wie das möglich ist.

Um eine kognitiv schwierige Aufgabe zu beherrschen braucht es über 10'000 Stunden Übung. Egal ob es das Spielen eines Musikinstruments oder das Zusammenarbeiten in einem Team ist. Viele junge Erwachsene haben in ihrem Leben bereits über 10'000 Stunden mit Spielen verbracht. Darum sind sie Meister in Problemlösung, schnellem Fehlschlagen und kreativem Ausprobieren. Dies ist exakt die in agilen Teams benötigte Denkweise. Gamer haben ein ausgeprägtes lösungsorientiertes mentales Modell.

Ein funktionierendes Team ist mehr als eine zusammengewürfelte Gruppe von Entwicklern. In effektiven Teams bilden sich Muster, welche helfen, das Projektziel früher und besser zu erreichen. In dieser Session erkläre ich die Muster, welche ich in Teams immer wieder beobachte und zeige, wie ihr diese in eurem Team einbringen könnt.

In deinem aktuellen Projekt gibt es viel Legacy Code mit wenigen Tests. Bugfixes führen endlos zu weiteren Bugs, und Änderungen sind nur mit sehr viel Aufwand möglich. Ohne das Sicherheitsnetz durch Tests bleibt die Softwareentwicklung nahezu stehen. Wir zeigen euch wie ihr Test Driven Development (TDD) und Acceptance Test Driven Development (ATDD) in ein bestehendes Projekt einbringt. Durch die dabei enstehende automatisierte Testsuite streichst du Folgefehler aus deinem Projektvokabular. Änderungen in deinem Projekt sind um Faktoren schneller. Erlebe etablierte Praktiken die du in deinem Projekt erfolgreich einsetzen kannst. Diese Präsentation zeigt auf, wieso ein Big Bang Rewrite keine Lösung ist. Stattdessen zeigen wir, wie kontinuierlich Funktionalität geliefert wird und trotzdem die Code Basis Stück für Stück verbessert werden kann.

„Hätten wir zu Beginn des Projektes all das gewusst, was wir am Ende wussten, hätten wir nur halb so lange gebraucht.“ So oder ähnlich, tönt es in vielen Projekten. Was können wir also unternehmen, um uns das benötigte Wissen schnell und möglichst früh anzueignen? Und wie lernt ein Team als Einheit und nicht als Gruppe von Individuen? Ich berichte aus den Projekten der bbv Software Services AG über lernfreundliche Umgebungen und Methoden des Lernens als Team. Nehmen Sie den vorgestellten Methodenkatalog mit in Ihre Teams und beschleunigen Sie das Erklimmen der Lernkurve.

In diesem Theater erörtern wir die Fragestellungen des Continuous Delivery vom Verkauf bis zum Betrieb. Im Speziellen ergründen wir die Herausforderungen und Lösungen in den folgenden Bereichen: Kommunikation, Technical-Depth, Robustheit der Testfälle im funktionalen und nicht-funktionalen Kontext, sowie der Automatisierung der Pipeline bis in den Betrieb. Im Rahmen unseres Theaters zeigen wir konkrete Lösungen auf um die Time-to-Market zu verkürzen und die Qualität zu erhöht. Der Vortrag enthält eine filmische Einleitung in die Themen. Idee und Schnitt: Jörg Bächtiger, Mitwirkende: Sándor Pongrácz und Urs Enzler

Test-driven Development und Acceptance Test-driven Development sind Kernpraktiken von agilen Teams. Konsequent angewendet führen sie zu weniger Fehlern im Code und erhöhen die Entwicklungsgeschwindigkeit. Sehen Sie in dieser Einführung, wie TDD/ATDD funktioniert, Unit Tests und Akzeptanztests Test-first geschrieben werden und welche Designprinzipien helfen, die Tests einfach zu halten.

Meistens wird Code nach Layern oder Tiers organisiert. Dies führt zu grossen Namespaces, welche unübersichtlich sind. Es ist schwer zu erkennen, was zusammengehört um ein einzelnes Feature umzusetzen. Wenn Source Code nach Features gruppiert ist, ist die Software einfacher zu verstehen, zu verändern und zu erweitern. Nach den theoretischen Grundlagen, zeige ich an meinem aktuellen Kundenprojekt, wie wir unseren Code strukturieren und welchen Gewinn wir daraus ziehen. Buzzwords: loosely-coupled components built of classes with high cohesion, IoC, product-family

Agile sein bedeutet schnell auf Änderungen reagieren können. Dies verlangt aber, dass die Software jederzeit potenziell auslieferbar ist. Denn sonst habe ich einen Rattenschwanz an Aufgaben die ich zuerst abschliessen muss, bevor das neue Ziel in Angriff genommen werden kann. Qualität muss somit von Anfang an in die Software eingebaut sein und kann nicht am Schluss hinein getestet werden. In dieser Präsentation stelle ich die Praktiken und Methoden vor, welche bbv Software Services AG in ihren Projekten einsetzt um die Qualität auf agile Weise zu sichern. Stichworte: TDD, ATDD, Pair Programming, Testpyramide, schnelles Feedback

Karlsruher Entwicklertag 2012

HSR 2012, Basta! 2011, ZHAW 2010

The presentation is about how we get quality into our code. Buzzwords: Focus, frequent measurements, strong team, clean code, pair programming, test driven development, acceptance tests, continuous integration, collective code ownership, team learning.

Nothing changes more than the user interface in an Agile project. Mostly because all stakeholders can discuss what they see. Therefore, the design of the user interface needs to be as Agile as possible.

SET 2009, bbv System Event 2009

In this presentation, I’ll show you how we evolve the architecture of our software Sprint per Sprint (we develop software using Scrum). You’ll see the architectural challenges you have to face when developing software in an agile way and how we cope with them to get an architecture that grows together with software.