Worauf kommt es bei einer effektiven und nachhaltigen Scrum-Einführung an? Worauf muss dabei insbesondere das Management achten? In diesem Praxisbericht stellen wir vor, wie eine solche Scrum-Einführung schnell und erfolgreich bei Deutschlands größter Direktversicherung gelungen ist. Ähnlich wie beim Übergang von einer traditionellen Brötchenbäckerei hin zu einer meisterhaften Konditorei kommt es dabei, insbesondere zu Anfang, auf die Einhaltung bewährter Rezepte sowie die passenden Zutaten und das Erlernen der notwendigen Handgriffe an. So können ein geeignetes Pilot-Projekt, Value-Orientierung als Grundgedanke, die Begleitung durch einen Agile Coach, das bedachte Agieren des Managements und weitere Faktoren die Erfolgswahrscheinlichkeit enorm steigern. Ein solches Projekt wie in diesem Beispiel ist einer der ersten und wichtigsten Schritte, um eine Veränderungsinitiative hin zu einer agilen Organisation voranzutreiben. Dr. Martin Burger und Jochen Dinter gehen in den kritischen Dialog über die Erfolgskriterien und was man dabei beachten sollte.
Wir wollen Feedback – oft und schnell. Das setzt schlanke, häufige und qualitativ hochwertige Releases voraus. Doch komplexe Software, an der mehrere Scrum-Teams arbeiten, stellt hohe Anforderungen an Delivery-Prozesse. Kann man dabei ohne Branches arbeiten? Kommt man mit dem Testen noch nach? Und Datenbankänderungen ...? Dieser Vortrag schaut hinter die Kulissen von AutoScout24, eines europaweit erfolgreichen Onlinemarktplatzes, der mit agilen Methoden Continuous Delivery Realität werden lässt.
Continuous Integration: How I stopped guessing if that merge was badJoe Ferguson
Continuous integration / deployment can be a daunting task. Especially if you are a team of one, or one among a small team. TeamCity is "continuous integration for everyone" It's a self hosted CI build server that is highly customizable for just about any project. I've built RocketFuel's CI/CD system on a spare box with TeamCity and customized it to handle legacy PHP applications and modern framework based projects. We'll cover install and configuration and all of the flexibility of setting up projects at that build, test, report errors, and trigger deployments for various application scenarios.
Worauf kommt es bei einer effektiven und nachhaltigen Scrum-Einführung an? Worauf muss dabei insbesondere das Management achten? In diesem Praxisbericht stellen wir vor, wie eine solche Scrum-Einführung schnell und erfolgreich bei Deutschlands größter Direktversicherung gelungen ist. Ähnlich wie beim Übergang von einer traditionellen Brötchenbäckerei hin zu einer meisterhaften Konditorei kommt es dabei, insbesondere zu Anfang, auf die Einhaltung bewährter Rezepte sowie die passenden Zutaten und das Erlernen der notwendigen Handgriffe an. So können ein geeignetes Pilot-Projekt, Value-Orientierung als Grundgedanke, die Begleitung durch einen Agile Coach, das bedachte Agieren des Managements und weitere Faktoren die Erfolgswahrscheinlichkeit enorm steigern. Ein solches Projekt wie in diesem Beispiel ist einer der ersten und wichtigsten Schritte, um eine Veränderungsinitiative hin zu einer agilen Organisation voranzutreiben. Dr. Martin Burger und Jochen Dinter gehen in den kritischen Dialog über die Erfolgskriterien und was man dabei beachten sollte.
Wir wollen Feedback – oft und schnell. Das setzt schlanke, häufige und qualitativ hochwertige Releases voraus. Doch komplexe Software, an der mehrere Scrum-Teams arbeiten, stellt hohe Anforderungen an Delivery-Prozesse. Kann man dabei ohne Branches arbeiten? Kommt man mit dem Testen noch nach? Und Datenbankänderungen ...? Dieser Vortrag schaut hinter die Kulissen von AutoScout24, eines europaweit erfolgreichen Onlinemarktplatzes, der mit agilen Methoden Continuous Delivery Realität werden lässt.
Continuous Integration: How I stopped guessing if that merge was badJoe Ferguson
Continuous integration / deployment can be a daunting task. Especially if you are a team of one, or one among a small team. TeamCity is "continuous integration for everyone" It's a self hosted CI build server that is highly customizable for just about any project. I've built RocketFuel's CI/CD system on a spare box with TeamCity and customized it to handle legacy PHP applications and modern framework based projects. We'll cover install and configuration and all of the flexibility of setting up projects at that build, test, report errors, and trigger deployments for various application scenarios.
Using CI for continuous delivery Part 3Vishal Biyani
This is part 3 of "Using CI for continuous delivery" in which we test drive Bamboo. More details can be found at www.vishalbiyani.com/ci-continuous-delivery
Using CI for continuous delivery Part 4Vishal Biyani
This is part 4 of "Using CI for continuous delivery" in which we test drive Jenkins. More details can be found at www.vishalbiyani.com/ci-continuous-delivery
Using CI for continuous delivery Part 2Vishal Biyani
This is part 3 of "Using CI for continuous delivery" in which we test drive TeamCity. More details can be found at www.vishalbiyani.com/ci-continuous-delivery
Using CI for continuous delivery Part 1Vishal Biyani
This is part 3 of "Using CI for continuous delivery" in which we test drive Go. More details can be found at www.vishalbiyani.com/ci-continuous-delivery
Who let the robot out? Qualitativ hochwertige Software durch Continuous Integ...Timo Stollenwerk
Continuous Integration ist Begriff aus der Softwareentwicklung, der den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung beschreibt. Das Ziel der kontinuierlichen Integration ist die Steigerung der Softwarequalität. Jede "Integration" führt zu einem automatisierten Build-Prozess der verschiedene Software-Tests und Code-Analyseschritte ausführt um Fehler so früh wie möglich erkennen und beheben zu können.
Dieser Vortrag wird die Prinzipien der Kontinuierlichen Integration vorstellen und aufzeigen wie diese für ein Python-Projekt umgesetzt werden können. Dabei werden die Erfahrungen aus dem Betrieb des CI-Servers für das Plone Projekt, eines der größten Python-basierten Open Source Projekte, vorgestellt. Unter anderem werden die folgenden Themen behandelt:
- Aufsetzen eines Continous Integration Servers mit Travis-CI oder Jenkins
- Einbindung verschiedener Versionskontrollsysteme
- Das Ausführen verschiedener Tests und die Analyse der Code-Qualität für jede Integration
- Wie Jenkins verwendet werden kann um automatisch eine Software Dokumentation zu erstellen, die Entwickler zu benachrichtigen, Software Releases zu erstellen und Software zu deployen
- Das Schreiben und kontinuierliche Ausführen von funktionalen Akzeptanztests, basierend auf Robot Framework
Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasistandard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen zu bekommen. Wie breche ich Silos jenseits von Dev und Ops auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Welche Strukturen von heute stehen DevOps im Weg?
www.opitz-consulting.com
Zu einem guten Gericht gehören gute Zutaten. So ist es auch mit einer Continuous-Delivery-Umgebung.
Was macht eine gute Developer Experience aus? Aus welchen Zutaten bestehen moderne Continuous-Delivery-Umgebungen? Wir schauen uns an, welche Zutaten man braucht und durch welche Produkte sich diese abdecken lassen.
An welchen Qualitätsattributen müssen sich CD-Plattformarchitekturen messen lassen?
So wie man aus den gleichen Zutaten Gerichte für die unterschiedlichen Geschmäcker bauen kann, so kann man auch unterschiedliche Entwicklerkulturen bedienen.
Lernen Sie, wie Sie das Rezept für ihren Lieblingsstack finden können.
360 Grad Projekt Review Christian Bauer PMI SUMMITChristian Bauer
Wie gut sind Ihre Softwareprojekte unterwegs? Gibt es
Sanierungsbedarf? Wenn ja, welchen?
Oft sind Probleme im Projekt deutlich spürbar, aber die
Sichtweisen darauf unterschiedlich. Wie damit umgehen?
Wer hier auf schnelle Lösungen, sogenannte „Quick-Wins“,
setzt, läuft Gefahr Symptombekämpfung zu betreiben, im
schlimmsten Fall: „Leichen schminken“.
Ein 360 Grad Projekt-Review liefert Antworten auf diese
Fragen, und schafft eine tragfähige Entscheidungsbasis für
das weitere Vorgehen. 360 Grad heißt, dass dabei alle, für
den Projekterfolg wesentlichen Faktoren, betrachtet werden.
Neben dem Projektmanagement auch die technische Architektur,
der Entwicklungsprozess, Skills und Kommunikation
des Teams, sowie die Einbettung in die Organisation. Warum?
Der TÜV prüft ja auch nicht nur die Lenkung!
Doch wie kann ein solches 360 Grad Review kostengünstig
abgewickelt werden? Was ist dabei zu beachten? Wovon
können sie ausgehen? Welche Kompetenzen braucht es
dazu? Welche Artefakte sind zu reviewen? Und wie erzielen
sie für unpopuläre Ergebnisse die notwendige Akzeptanz?
Lesen sie weiter.
"Agiles Testen" wird gerade intensiv diskutiert.
Was steckt dahinter? Was für Konsequenzen ergeben sich daraus für unsere Scrum-Teams? Oder verbirgt sich gar eine neue Testmethode hinter diesem Begriff?
In diesem Vortrag erläutern wir den Weg vom Scrum-Team hin zu einem Agilen Team, wie Crispin und Gregroy es nennen. Sie geben damit die Antwort auf die Frage, wie die Rolle der QS in einem Scrum-Team wahrgenommen werden kann. Wir zeigen, welche Konsequenzen sich daraus für die Teammitglieder und ihre Aufgaben ergeben und wie Sie Ihr Agiles Team zum Fliegen bekommen!
In diesem Referat erhalten Sie eine kurze Einführung zu Scrum und gehen auf die Möglichkeiten ein, wie Testing in agilen Projekten angewendet und verbessert werden kann. Besonderes Augenmerk gilt dabei dem Einsatz eines Embedded Scrum Testers, der explorativen Testmethodik und dem Session Based Testing.
„Bekommen Sie Ihre SQL Datenbank unter Kontrolle”
Ein Großteil des existierenden .NET Codes steht unter Quellcodeverwaltung und bereits heute verwenden viele Anwendungsentwickler irgendeine Form von Continuous Integration. Die Datenbankentwickler hängen an dieser Stelle leider ein wenig hinterher. Dabei sind gerade die Daten das Herzstück einer Anwendung und Änderungen an Datenbankstrukturen daher besonders komplex. Der erste Schritt um eine Verbesserung herbeizuführen ist es, die Datenbank ebenfalls unter Quellcodeverwaltung zu stellen. Das erleichtert nicht nur die Zusammenarbeit mit anderen Teammitgliedern und ermöglicht ein einfacheres Deployment, sondern es bildet auch die Grundlage für Continuous Integration, sowie automatisiertes Testing.
Dieser User-Group Abend zeigt:
* wie man seine SQL Datenbank genauso einfach in die Quellcodeverwaltung bringt wie .NET Code
* wie man seine Datenbank direkt aus der Quellcodeverwaltung heraus deployen kann und
* wie man einen ersten Schritt in Richtung Continous Integration machen kann
Eine Entdeckungsreise zum Land der Software-QualitätMarco Ravicini
Die Softwarequalität zu verbessern, ist meist leichter gesagt als getan. Was versteht man genau unter Softwarequalität? Und wie kann sie gesteuert werden?
In dieser Präsentation machen wir zusammen eine Reise durch das Thema Software-Qualität anhand einer Karte. Sie nimmt uns auf Entdeckungsreise, die Produkt und Servicequalität. Wir segeln dabei durch den «Stream of Team Building», machen eine kurze Pause im «Gulf of Legacy Code», bevor wir an der «Bug Bay» und dem «Release Monster» zum Land «Product Release» kommen. Gehen wir auf Schatzsuche!
Aus der Präsentation nimmst du eine Karte mit, welche du zusammen mit deinem Team erforschen kannst. Sie bietet eine Diskussionsgrundlage für den nächsten Schritt zu einer besseren Qualität.
In diesem Vortrag schildern Stefan Roock und Henning Wolf (akquinet agile Gmbh) ihre Erfahrungen, die sie bei der Anwendung des KAIZEN-Prinzips in einem großen Individualentwicklungsprozess gemacht haben.
Der Vortrag wurde auf den XP Days Germany 2006 gehalten.
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0Michael Fischlein
Welche Auswirkung hat eine agiler Softwareentwicklungsprozess auf den Softwaretest und die Qualitätssicherung? Welche Änderungen muss man beachten und wie muss und kann man Softwaretester auf diese Veränderungen vorbereiten.
Dieser Vortrag wurde auf der iqnite 2014 von Michael Fischlein gehalten.
Der Vortrag von der Webinale 2012 geht auf Aspekte des Continuous Deliver ein:
1) Business Reasoning: Was ist die Motivation hinter Continuous Delivery? Was bedeutet LEAN Product Development?
2) LEAN applied: Wie bekommt man LEAN in die Organisation? Wer ist dadurch betroffen?
3) Build-Measure-Learn: CD als "Build"-Tool
4) CD @ FRS24
a) Maßnahmen und Impact auf unsere Java-Plattform
b) Maßnahmen und Impact bei unseren RoR-Plattformen
5) Lessons Learned
Using CI for continuous delivery Part 3Vishal Biyani
This is part 3 of "Using CI for continuous delivery" in which we test drive Bamboo. More details can be found at www.vishalbiyani.com/ci-continuous-delivery
Using CI for continuous delivery Part 4Vishal Biyani
This is part 4 of "Using CI for continuous delivery" in which we test drive Jenkins. More details can be found at www.vishalbiyani.com/ci-continuous-delivery
Using CI for continuous delivery Part 2Vishal Biyani
This is part 3 of "Using CI for continuous delivery" in which we test drive TeamCity. More details can be found at www.vishalbiyani.com/ci-continuous-delivery
Using CI for continuous delivery Part 1Vishal Biyani
This is part 3 of "Using CI for continuous delivery" in which we test drive Go. More details can be found at www.vishalbiyani.com/ci-continuous-delivery
Who let the robot out? Qualitativ hochwertige Software durch Continuous Integ...Timo Stollenwerk
Continuous Integration ist Begriff aus der Softwareentwicklung, der den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung beschreibt. Das Ziel der kontinuierlichen Integration ist die Steigerung der Softwarequalität. Jede "Integration" führt zu einem automatisierten Build-Prozess der verschiedene Software-Tests und Code-Analyseschritte ausführt um Fehler so früh wie möglich erkennen und beheben zu können.
Dieser Vortrag wird die Prinzipien der Kontinuierlichen Integration vorstellen und aufzeigen wie diese für ein Python-Projekt umgesetzt werden können. Dabei werden die Erfahrungen aus dem Betrieb des CI-Servers für das Plone Projekt, eines der größten Python-basierten Open Source Projekte, vorgestellt. Unter anderem werden die folgenden Themen behandelt:
- Aufsetzen eines Continous Integration Servers mit Travis-CI oder Jenkins
- Einbindung verschiedener Versionskontrollsysteme
- Das Ausführen verschiedener Tests und die Analyse der Code-Qualität für jede Integration
- Wie Jenkins verwendet werden kann um automatisch eine Software Dokumentation zu erstellen, die Entwickler zu benachrichtigen, Software Releases zu erstellen und Software zu deployen
- Das Schreiben und kontinuierliche Ausführen von funktionalen Akzeptanztests, basierend auf Robot Framework
Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasistandard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen zu bekommen. Wie breche ich Silos jenseits von Dev und Ops auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Welche Strukturen von heute stehen DevOps im Weg?
www.opitz-consulting.com
Zu einem guten Gericht gehören gute Zutaten. So ist es auch mit einer Continuous-Delivery-Umgebung.
Was macht eine gute Developer Experience aus? Aus welchen Zutaten bestehen moderne Continuous-Delivery-Umgebungen? Wir schauen uns an, welche Zutaten man braucht und durch welche Produkte sich diese abdecken lassen.
An welchen Qualitätsattributen müssen sich CD-Plattformarchitekturen messen lassen?
So wie man aus den gleichen Zutaten Gerichte für die unterschiedlichen Geschmäcker bauen kann, so kann man auch unterschiedliche Entwicklerkulturen bedienen.
Lernen Sie, wie Sie das Rezept für ihren Lieblingsstack finden können.
360 Grad Projekt Review Christian Bauer PMI SUMMITChristian Bauer
Wie gut sind Ihre Softwareprojekte unterwegs? Gibt es
Sanierungsbedarf? Wenn ja, welchen?
Oft sind Probleme im Projekt deutlich spürbar, aber die
Sichtweisen darauf unterschiedlich. Wie damit umgehen?
Wer hier auf schnelle Lösungen, sogenannte „Quick-Wins“,
setzt, läuft Gefahr Symptombekämpfung zu betreiben, im
schlimmsten Fall: „Leichen schminken“.
Ein 360 Grad Projekt-Review liefert Antworten auf diese
Fragen, und schafft eine tragfähige Entscheidungsbasis für
das weitere Vorgehen. 360 Grad heißt, dass dabei alle, für
den Projekterfolg wesentlichen Faktoren, betrachtet werden.
Neben dem Projektmanagement auch die technische Architektur,
der Entwicklungsprozess, Skills und Kommunikation
des Teams, sowie die Einbettung in die Organisation. Warum?
Der TÜV prüft ja auch nicht nur die Lenkung!
Doch wie kann ein solches 360 Grad Review kostengünstig
abgewickelt werden? Was ist dabei zu beachten? Wovon
können sie ausgehen? Welche Kompetenzen braucht es
dazu? Welche Artefakte sind zu reviewen? Und wie erzielen
sie für unpopuläre Ergebnisse die notwendige Akzeptanz?
Lesen sie weiter.
"Agiles Testen" wird gerade intensiv diskutiert.
Was steckt dahinter? Was für Konsequenzen ergeben sich daraus für unsere Scrum-Teams? Oder verbirgt sich gar eine neue Testmethode hinter diesem Begriff?
In diesem Vortrag erläutern wir den Weg vom Scrum-Team hin zu einem Agilen Team, wie Crispin und Gregroy es nennen. Sie geben damit die Antwort auf die Frage, wie die Rolle der QS in einem Scrum-Team wahrgenommen werden kann. Wir zeigen, welche Konsequenzen sich daraus für die Teammitglieder und ihre Aufgaben ergeben und wie Sie Ihr Agiles Team zum Fliegen bekommen!
In diesem Referat erhalten Sie eine kurze Einführung zu Scrum und gehen auf die Möglichkeiten ein, wie Testing in agilen Projekten angewendet und verbessert werden kann. Besonderes Augenmerk gilt dabei dem Einsatz eines Embedded Scrum Testers, der explorativen Testmethodik und dem Session Based Testing.
„Bekommen Sie Ihre SQL Datenbank unter Kontrolle”
Ein Großteil des existierenden .NET Codes steht unter Quellcodeverwaltung und bereits heute verwenden viele Anwendungsentwickler irgendeine Form von Continuous Integration. Die Datenbankentwickler hängen an dieser Stelle leider ein wenig hinterher. Dabei sind gerade die Daten das Herzstück einer Anwendung und Änderungen an Datenbankstrukturen daher besonders komplex. Der erste Schritt um eine Verbesserung herbeizuführen ist es, die Datenbank ebenfalls unter Quellcodeverwaltung zu stellen. Das erleichtert nicht nur die Zusammenarbeit mit anderen Teammitgliedern und ermöglicht ein einfacheres Deployment, sondern es bildet auch die Grundlage für Continuous Integration, sowie automatisiertes Testing.
Dieser User-Group Abend zeigt:
* wie man seine SQL Datenbank genauso einfach in die Quellcodeverwaltung bringt wie .NET Code
* wie man seine Datenbank direkt aus der Quellcodeverwaltung heraus deployen kann und
* wie man einen ersten Schritt in Richtung Continous Integration machen kann
Eine Entdeckungsreise zum Land der Software-QualitätMarco Ravicini
Die Softwarequalität zu verbessern, ist meist leichter gesagt als getan. Was versteht man genau unter Softwarequalität? Und wie kann sie gesteuert werden?
In dieser Präsentation machen wir zusammen eine Reise durch das Thema Software-Qualität anhand einer Karte. Sie nimmt uns auf Entdeckungsreise, die Produkt und Servicequalität. Wir segeln dabei durch den «Stream of Team Building», machen eine kurze Pause im «Gulf of Legacy Code», bevor wir an der «Bug Bay» und dem «Release Monster» zum Land «Product Release» kommen. Gehen wir auf Schatzsuche!
Aus der Präsentation nimmst du eine Karte mit, welche du zusammen mit deinem Team erforschen kannst. Sie bietet eine Diskussionsgrundlage für den nächsten Schritt zu einer besseren Qualität.
In diesem Vortrag schildern Stefan Roock und Henning Wolf (akquinet agile Gmbh) ihre Erfahrungen, die sie bei der Anwendung des KAIZEN-Prinzips in einem großen Individualentwicklungsprozess gemacht haben.
Der Vortrag wurde auf den XP Days Germany 2006 gehalten.
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0Michael Fischlein
Welche Auswirkung hat eine agiler Softwareentwicklungsprozess auf den Softwaretest und die Qualitätssicherung? Welche Änderungen muss man beachten und wie muss und kann man Softwaretester auf diese Veränderungen vorbereiten.
Dieser Vortrag wurde auf der iqnite 2014 von Michael Fischlein gehalten.
Der Vortrag von der Webinale 2012 geht auf Aspekte des Continuous Deliver ein:
1) Business Reasoning: Was ist die Motivation hinter Continuous Delivery? Was bedeutet LEAN Product Development?
2) LEAN applied: Wie bekommt man LEAN in die Organisation? Wer ist dadurch betroffen?
3) Build-Measure-Learn: CD als "Build"-Tool
4) CD @ FRS24
a) Maßnahmen und Impact auf unsere Java-Plattform
b) Maßnahmen und Impact bei unseren RoR-Plattformen
5) Lessons Learned
Innovation durch Scrum und Continuous DeliveryPeter Gfader
Kunden begeistern mit einem konstanten Fluss von Neuheiten
Zielgruppe: Scrum Practitioners die Ihren Prozess auf die nächste Ebene bringen wollen
Unternehmen kämpfen mit Bürokratie, Abhängigkeiten, Menschlichem Verhalten, Technischen Problemen und verlieren dabei das Ziel aus den Augen. Continuos Delivery ist mehr als eine technische Praktik, kann mit Scrum funktionieren und verändert die Weise wie wir Software entwickeln.
Wir werden beleuchten, wie wir öfter etwas Nützliches liefern können, wie wir den Kunden in den Mittelpunkt unserer Bemühungen stellen und was das für Auswirkungen auf ein Unternehmen hat. Ist ein potentielles Endresultat das Lean Startup?
Usability intern oder extern testen (WUD 2010)Sandra Griffel
Gerade bei kleinen und mittleren Projekten sind teure Usability-Evaluationen im Budget nicht vorgesehen. Dennoch sind diese Methoden bei der Entwicklung von interaktiven Anwendungen unverzichtbar. Die Frage ist also, welche Maßnahmen intern kosten- und zeiteffizient geleistet werden können und in welchen Fällen eine externe Evaluation der Gebrauchstauglichkeit notwendig ist.
Unterstützend werden Methoden für internes und externes Testing vorgestellt ...
OOP 2017 - Durchdenken oder einfach mal machen?Ralf Kruse
Wie viel Vorbereitung und Klarheit braucht es eigentlich zur effektiven Entwicklung guter Produkte? Wann ist der Zeitpunkt gekommen mutig auszuprobieren & wann ist es fahrlässig? Wann ist es notwenig etwas gut zu durchdenken & wann ist es ineffektiv?
Eine Suche nach der richtigen Balance zwischen zwei vermeintlich gegensätzlichen, unvereinbaren Positionen.
Ähnlich wie Wie verändert sich Testen mit Continuous Delivery? (20)
Wrestling with Conway's Law: How to support cross-functional teams working on...Dr. Alexander Schwartz
Talk for the Agile Testing Days 2023.
Mel Conway published in 1968 the observation that the communication structure of a company has an impact on the architecture of the produced software components.
Nowadays many organizations use the “feature team approach”, that is, a preference for cross-functional teams which deliver value without depending on other teams. An implication is that several feature teams are going to work on the same components, which implies that the traditional concepts of strong component ownership are no longer applicable. This generates a myriad of challenges, e.g. teams waiting for code review from other teams.
In this talk we first revisit Conway’s Law and then explore what is required to ensure success of feature teams working on shared components. First and foremost, does the architecture, the processes, etc. really support the requirement of ease of changing a shared component?
Talk presented at the Agile Tour Vienna 2016 conference.
http://agiletourvienna.at/#scheduleModal-does-agile-mean-we-have-less-time-for-testing
ABSTRACT:
In the last decade, the speed of our industry has increased greatly. Agile Development, DevOps and Continuous Delivery are the main drivers for this paradigm shift which has now become widely accepted.
Ten years ago, it was common to only release a couple of new versions a year. Today, there are companies delivering hundreds of software deployments per day. This isn’t only true in IT, but also e.g. for Tesla-Automobile, which delivers its software updates a few times a week.
Where does quality happen when we’re releasing this often? Is it possible to have proper quality management and is there enough time for testing? How can we reduce what could be weeks of testing to deliver new features to our clients on a daily basis?
Alex is a long-term enthusiast for this topic. Based on his experiences with various products and companies, he’ll share his insights into the mystery of “faster testing”. The key questions are:
- When – When do we test?
- What – What should we test?
- Which quality aspects are important?
- How – How do we test? Which techniques are helpful?
- Who – Who is involved in testing, test automation, etc.?
- How much – How much should we test?
Furthermore, we discuss the financial benefits of Agile Testing and aiming for Continuous Quality. Last but not least we explore if it only exists in fairy tale land or if it is real.
Talk provided at ASQF meetup "Fachgruppentreffen" in Braunschweig, 18th August 2016
In the last decade, the speed of our industry has increased greatly. Agile Development, DevOps and Continuous Delivery are the main drivers for this paradigm shift which has now become widely accepted.
Ten years ago, it was common to only release a couple of new versions a year. Today, there are companies delivering hundreds of software deployments per day. This isn't only true in IT, but also e.g. for Tesla-Automobile, which delivers its software updates a few times a week.
Where does quality happen when we're releasing this often? Is it possible to have proper quality management and is there enough time for testing? How can we reduce what could be weeks of testing to deliver new features to our clients on a daily basis?
Alex is a long-term enthusiast for this topic. Based on his experiences with various products and companies, he'll share his insights into the mystery of "faster testing". The key questions are:
How can we guarantee quality
When do we test?
How do we test?
How often do we test and what don't we test?
and finallyt: Who does the testing?
Together we will discuss our common problems, approaches and best practices.
Flipcharts of the workshop (in german) "Splitting User Stories with Elefant Carpaccio", facicilated 7th June, 2016 at the Scrum-Day in Stuttgart.
#scrumday #scrumday16
Slides of a workshop facilitated by Fanny Pittack and Alex Schwartz at the conference Agile Testing Days 2015 in Potsdam.
Main Statement:
Change dojos are creating a safe environment for practicing skills for change agents. It sets fundamentals for you and allow you to perform change.
This workshop is for everyone who is involved in improving his or her environment. As the ATD 2015 conference theme states, mastering Agile might be the competitive edge for your organization – and this requires great skills to transform your environment, to change it towards the goal of Agile mastery.In our last years keynote “Insights of Happy Change Agents” we scratched the surface of how to become a “Happy Change Agent”, how to initiate changes with ease and enthusiasm, fun and success. In this workshop we aim to dive deeper.The first part of our workshop is dedicated to the “change dojo” format. Together with your pairing partner you simulate the interaction of a change agent with a team or coachee. We practice different scenarios and we will focus step by step on various aspects like pace, distance, keeping your own space, as well as communicating clearly with your body. This provides a chance to receive instant feedback how the change is perceived by the coachee. One key learning is to appreciate any sign of frustration as a valuable indicator.The second part is intended to storytelling and listening exercises. We all have buried a story of change that somehow failed. If you attend our workshop, please bring your story with you.
Key Learnings:
- Exercises to bring back to your workplace, to practice with your team
- How to be open for feedback and listen
- How to sketch your story on a story board
- How to use your frustration as indicator
- How to reflect in various situations
Audience:
Tester, Developer, Product Owner, Scrum Master, Agile Manager, Change Agents, Agile Coach
slides of a workshop (in German) facilitated at the ScrumDay 2015 (http://www.scrum-day.de/) in Stuttgart.
Lanyrd:
http://lanyrd.com/2015/scrum-day/sdpmgb/
Abstract:
Coding Dojos sind sehr bekannt und sind nun ein anerkanntes Hilfsmittel um Wissen zu vermitteln und unser Kung-Fu zu verbessern. Warum dieses Format, diese Lernmethode nicht auch für andere Themen verwenden?
In diesem Dojo fokussieren wir uns auf User Stories: ihre Akzeptanzkriterien und wie wir grosse Stories in kleinere zerschneiden können.
In Gruppenübungen werden wir unser Kung-Fu verbessern. Vielleicht wird Deine Gruppe auf Yoda-Niveau erreichen: alle Mini-Stories haben einen Wert und sind MMFs (minimal markatable features) im Sinne des Lean Startup?
Slides of a keynote talk by Fanny Pittack and Alexander Schwartz at the conference Agile Testing Days 2014 in Potsdam. http://www.agiletestingdays.com/ #AgileTd
presented at Berlin DevOps Meetup April 29, 2014.
Explains our experiences establishing DevOps and Continuous Delivery for the Places RESTful API at HERE, a Nokia business.
How our product, the HERE Places RESTful API, ripened over time and how our understanding of quality changed over time.
As every distinguished wine is the result of a long refining and ripening process, every software product is subject to a similar evolution, too. Of course along the journey of a product, the understanding of “Quality” is subject to major changes as well.
Lets join the 3-year journey of a software product through its various stages, from planning, seeding to its first wine tasting (that is, the beta offer), to selling the first bottles (that is, the service is used by other internal products), finally to its market readiness (that is, becoming a commercial B2B offer with SLAs).
The product under test is the Places RESTful API (places.demo.api.here.com), which delivers data for Places that are shown in various products, for instance for Nokia’s HERE.com maps.
We concentrate on three different aspects and how they change over time:
* the understanding of what quality means,
* the test strategy, and last but not least
* how to deal with the intrinsic complexity.
We are going to explore the post production deployment part of our process: How we ensure the high availability of this complex service, as well as which test techniques, feedback mechanisms and in particular which visualizations (monitoring 2.0) we leverage for this purpose.
Presented a the Agile Testing Days 2013.
Presented at the goto;conference in Berlin 2013 (http://gotocon.com/berlin-2013).
Most teams introducing Continuous Delivery face problems such as "How do we fit our 4-day QA phase into a daily release rhythm?"
The transition to a DevOps strategy and Continuous Delivery usually requires a significant readjustment of the testing approach.
Alex shares stories from various companies he worked for, and discusses different ideas on how to retrofit testing for frequent releases. This includes adapting the rhythm of testing, test techniques, scope of testing, and re-thinking the entire quality assurance approach.
presented at the conference Agile Testing Days 2012 in Berlin/Potsdam
Original version on prezi: http://prezi.com/o39xxactxm6o/how-releasing-faster-changes-testing/
ABSTRACT:
In his keynote at the ATD2011 Gojo Adzic covered the “Five key challenges for agile testers tomorrow”. The first one mentioned is the impact of shorter release cycles on testing: “release cycles will get shorter, so short even that there’s no time for testing.”
In this talk Alex shares what he learned about this topic during the last four years, on his journey with two companies. In both companies he helped to change the release rhythm dramatically, which had a deep impact on the all facets of the test strategy, of course including cooperation and communication structures.
Whereas some lessons learned are obvious, others are unexpected and even counter-intuitive.
6. Wann haben wir gute Qualität?
Wann?
Design
Planung
Dev Release
Zeit
Qualitäts-
Maß
Test /
Hardening
“Qualitäts-Schuld”
Risiko für den Zeitplan
gestresst!!!
7. Asynchron
• z. B. Security-tests
• …
Wie verteilen wir den Kuchen?
Wann?
Design
Planung
Dev Release
Skalieren
Früh
• TDD/ATDD
• Continuous
Integration
• Requirements
discussions
• Early Feedback
• …
Test /
Hardening Vermeiden
In production
- Sind alle Tests hilfreich?
- …
messen, observieren, …
8. Wann haben wir gute Qualität?
Wann?
Design
Planning
Dev Release
Test /
Hardening
Zeit
Qualitäts-
Maß
late testing
early testing
11. Wie einführen?
Was kommt zuerst?
schneller
testen
öfter
releasen
erst wenn wir schneller
testen können, dann können wir
öfter releasen
klar.
wie sollen wir etwas lernen
ohne üben?