AgileWelt · Test-driven development (TDD) eXtreme Programming (XP) Lean development ... KentBeck&und&Erich&Gamma:&JUnit Testgetriebene Entwicklung 173 Robert Martin hat in seinem

Agile WeltWie sich die Welt so weit gedreht hat, dass Agil der Mainstream geworden ist

Christoph Mathis, Agile Tuesday und ScrumTisch, 07. 06.2011

Forrester: „Agile Development is rapidly becoming the norm“

© 2010, Forrester Research, Inc. Reproduction ProhibitedMay 5, 2010

The Forrester Wave™: Agile Development Management Tools, Q2 2010 For Application Development & Delivery Professionals

2

AGILE DEVELOPMENT IS RAPIDLY BECOMING THE NORM

In a recent survey, 35% of surveyed organizations described their primary development method as Agile; Scrum, at 11%, was the most popular Agile development approach (see Figure 1). In a di!erent survey, we questioned the nature of Agile adoption and found that 39% of the organizations we surveyed consider their implementation mature (see Figure 2). "e mainstream business press is even starting to get on the Agile bandwagon, referencing its use at eBay as crucial to the success of eBay’s business.1 "is increased level of adoption has serious implications for development organizations’ tool use, changing not only the process model being followed but also the very nature of work undertaken and who is involved in that work.

Figure 1 Agile Is Organizations’ Primary Development Approach

Source: Forrester Research, Inc. 56100

ScrumAgile Modeling

Feature-driven development (FDD)Test-driven development (TDD)

eXtreme Programming (XP)Lean development

Microsoft Solutions Framework (MSF) for AgileAgile Data Method

Adaptive Software Development (ASD)Six Sigma

CrystalBehavior-driven development (BDD)

Dynamic Systems Development Method (DSDM)

Iterative developmentRational Unified Process (RUP)

SpiralWaterfall

Capability Maturity Model Integration (CMMI)ISO 9000

Do not use a formal process methodology

“Please select the methodology that most closely reflectsthe development process you are currently using.”

(select only one)

10.9%6.0%

3.8%3.4%

2.9%2.1%1.8%1.6%1.3%

0.9%0.3%

0.2%0.2%

16.3%2.7%

1.6%8.4%

2.5%2.5%

30.6%

Agile, 35%

Iterative, 21%

Waterfall, 13%

Base: 1,298 IT professionalsSource: Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2009

Quelle: The Forrester Wave. Develop Management Tools, Q2 2010

Forrester: Die meisten OrganisaJonen sehen ihre ImplemenJerung als ausgereiL an

© 2010, Forrester Research, Inc. Reproduction Prohibited May 5, 2010


3

Figure 2 Most Organizations View Their Agile Adoption As Mature

Scaling Agile Requires Automation

Our interviews with application development professionals revealed that scaling Agility is a common issue — and that scaling Agile practices requires implementing tools. !e vice president of a large "nancial company described the need for automation: “When you have one project on a whiteboard with Post-its, it is "ne, but when you have "ve or six projects, the whiteboard approach just does not cut it. We haven’t even got enough whiteboards.” Automation is required because:

· Sharing status is time-consuming. !is is particularly true when the team is spread across many locations and is working on many projects. !e ability to quickly and easily share status information is crucial when the team self-selects work and changes direction based on that work’s results.

· Many Agile practices require automation. As Agile implementations mature, teams adopt more-sophisticated practices associated with testing, architecture, and build. To be e#ective, these practices require a sound automation foundation that supports automated test integration, code comparison, and integrated build management.

· Retrospectives require information. As teams work through sprints, team members can make and record many important observations. !ese observations help improve the process and are a key input to retrospectives. Without automation, it is very hard to remember the status of a project at a particular moment or to be able to do analysis to improve working practices.


“How far has your adoption of Agile proceeded?”

Base: 52 development professionals who have adopted Agile(percentages do not total 100 because of rounding)

Source: Q3 2009 Global Agile Adoption Online Survey

We have just startedadopting Agile methods

25%

We are still evaluatingAgile and have not

yet begun to adopt it6%

We have a mature implementationof Agile methods

39%

We are midway inour adoption of Agile

31%


Forrester: zwei Zyklen treiben agiles Projektmanagement

© 2010, Forrester Research, Inc. Reproduction Prohibited May 5, 2010


5

Figure 3 Two Closed Loops Drive Agile Automation

Dashboards Enable Visibility And Progress

Measurement and so!ware development have historically been poor bedfellows; heated debates abound about the value of measuring x or y on development projects.2 Agile changes this with a clear focus on progress, quality, and status metrics. It also changes who is interested in measures, making measurement one of the team’s key responsibilities. "is increased focus on dashboards requires teams to provide:

· Progress information on tasks. "e team creates tasks and selects them for work, with individuals committing estimates and reporting progress against this work. Tasks become the primary unit of discussion in daily Scrum meetings. Tasks are also linked with other artifacts such as builds and test results.

· Linkage between project artifacts and status information. Project status is greatly a#ected by the status of key project artifacts such as tests, builds, and code. Agile projects require that teams report this information in a timely manner in a way that shows both the status and state of these artifacts. For example, teams must report the status of the build and its relationship with completed tests. "is information allows the team to see which tests are outstanding and which have been completed. By aggregating this information across the project, the team can understand the project’s true status.


Production planningclosed loop

Production controlclosed loop

Change management Service management

Portfolio management

Change-awarecontinuous integration

JIT demandmanagement

Releasemanagement

Testing and quality assurance

Build and software

configurationmanagement

Deployment

Project management

Forrester argumenJert hier:-‐ Zur Skalierung braucht man Tools-‐ die Tools müssen die wichJgen Treiber unterstützen


Qualität, Korrektheit und Testen

Kurze Geschichte des Qualitätsmanagement

Wann Schlagwort Vorreiter In der SoLware?

um 1900 Qualitätskontrolle nachgelagert, AussorJeren fehlerhaLer Produkte Ford, Taylor ???

um 1930 QualitätsprüfungSteuerung basiert auf StaJsJken Shewart ???

um 1960 Vorbeugende Massnahmen im ganzen Unternehmen W.E.Deming JUnit

um 1985 Null-‐Fehlerstrategie Six Sigma ???

um 1990 Umfassendes QualitätskonzeptQualität als Systemziel, TQM

Ishikawa, W.E.Deming, TQM ???

hcp://de.wikipedia.org/wiki/Qualit%C3%A4tsmanagement

TDD: Das Programm ist richJg

„Analyze how a proof can be given that a class of computaJons obeys certain requirements -‐ that ist, explicitly state the condi,ons which must hold if we are to prove that an algorithm performs correctly; then write write a program that makes the condi,ons come true“Edsger Dijkstra: A ConstrucJve Approach to the Problem of Program Correctness, 1968

Kent Beck und Erich Gamma: JUnit

Testgetriebene Entwicklung

173

Robert Martin hat in seinem Buch „Clean Code“ drei Regeln für testgetriebene Entwicklung beschrieben: ! „Du darfst keinen Produktionscode schreiben, wenn Du keinen Unit-Test hast, der

fehlschlägt76.“ – die Regel, nur dann neuen (Produktiv-) Code zu schreiben, wenn ein fehlschlagender Test hierfür existiert, haben wir bereits erwähnt. Wichtig dabei ist auch die Betonung auf „fehlschlagend“, es reicht also nicht aus, einen Test zu haben, dieser muss auch fehlschlagen. Umgekehrt ausgedrückt, wenn der Test „auf grün“ geht, dann darf nicht mehr im Produktivcode weiter entwickelt werden.

! „Du darfst nicht mehr Testcode schreiben als dafür nötig ist, dass der Test fehlschlägt – Kompilierfehler zählen als fehlgeschlagener Test77. “ – Wie oben bereits erwähnt darf nur ein Unit-Test geschrieben werden und davon nur soviel, damit der Test fehlschlägt. Diese Regel hilft uns, auch den Testcode einfach und sauber zu halten und beim Schreiben von Tests ebenso kleine Schritte zu gehen.

! „Du darfst nicht mehr Produktionscode schreiben als dafür nötig ist, dass der aktuelle Test erfolgreich wird78.“ – Im Klartext bedeutet diese Regel, dass wir nur den allereinfachsten Code schreiben dürfen, um diesen Test zu befriedigen (und die bisherigen Tests auf Grün zu halten).

Die letzte der drei Regeln von „Uncle Bob“ hat weitreichende Konsequenzen. Wer diese wirklich beherzigt, ist gezwungen, zum Beispiel auch mal eine Konstante oder ein Literal als Rückgabewert einer neuen Funktion zu liefern. Erst mit den nächsten, aufkommenden Testfällen wird im Zuge des Refaktorisierens der Algorithmus verbessert. Dieser Schritt ist die Keimzelle von emergenten Design und evolutionärer Architektur. In weiterer Konsequenz bedeutet das, dass keine einzige Zeile neuer Code geschrieben werden darf, wenn kein fehlschlagender Test existiert und wie bereits erwähnt, das Refaktorisieren zum eigentlichen „Code-Entwickeln“ wird., ausgehend vom wirklich einfachsten nur erdenklichen Lösungsweg. Hier spiegeln sich die Ideen von zwei sehr wichtigen Prinzipien – erstens „Keep it simple, stupid“ und zweitens „Premature Optimization“ (siehe dazu auch Kapitel 11 zu Clean Code). In Abbildung 9.5 sind die zulässigen Pfade zwischen den Rot- und Grün-Phasen bei TDD eingezeichnet.

Abbildung 9.5: Die möglichen Pfade bei TDD

76 You may not write production code until you have a failing unit test 77 You may not write more of a unit test than is sufficient to fail. And not compiling is failing. 78 You may not write more production code than is sufficient to pass the currently failing test

GREENRED

Write failing test

Implement test

RefactorProduction

code

Refactortests

Unsafe Refactoring

path

UselessTests

Remove code

Remove tests

Die Struktur der SoLware

Die bleibenden Ziele der SoLwareentwicklung

Langlebige ZieleAbstrakJon

Lose Kopplung / Kohäsion

Vermeide hohe Kosten in späten Änderungen

Verschiedene Micel werden ausprobiertStrukturierte Programmierung

Hohe Programmiersprachen

ObjektorienJerte Programmierung

Wasserfall / Life Cycle Konzept

Clean Code

Refactoring TDD / ATDD

Agile Architektur

KonJnuierliche IntegraJon

Pair Programming

... inzwischen haben wir einige Micel

Die SoLware und das Business

TDD

User Story

KundeProduct Owner

Akzeptanz-kriterien

AutomatisierterAkzeptanztest

AuslieferbarerCode

ATDD

CI???

TDD

User Story

KundeProduct Owner

Akzeptanz-kriterien


AuslieferbarerCode

ATDD

CI

TDD

User Story

KundeProduct Owner

Akzeptanz-kriterien


AuslieferbarerCode

ATDD

CI

???

TDD

User Story

KundeProduct Owner

Akzeptanz-kriterien


AuslieferbarerCode

ATDD

CI

Strategische Planung

Inves,,onsentscheidungen

Produkte

Projekte

TDD

User Story

KundeProduct Owner

Akzeptanz-kriterien


AuslieferbarerCode

ATDD

CI

Strategische Planung

Inves,,onsentscheidungen

Produkte

Projekte

Scrum XP Lean Kanban

WIP-‐Limits

WIP-‐LimitsValue Stream

Value Stream

Agile Eng.Arbeit mit Kd.

Visualisierung

Selbstorganisierte Teams Inspect & Adapt Technische Exzellenz KonJnuierliche

Verbesserung

Respekt RetrospekJven Lernen fördern Empirische Prozesse

???

-‐-‐-‐

???

???

Herausforderungen

Technische Exzellenz... noch immer sind die Prinzipien des Agilen Engineering nicht allgemein verbreitet.

Checklisten-‐Umsetzung... wer eine agile Methode mit einem rigiden Prozess einführt oder umsetzt, ist nicht agil... Individuen und Interak@onen sind wich@ger als Prozesse (auch agile Prozesse) und Werkzeuge

Conway‘s Gesetz..organiza@ons which design systems ... are constrained to produce designs which are copies of the communica@on structures of these organiza@ons

Fünf organisatorische Gründe für Verschwendung

1.Zu viel Komplexität2.Fehlgeleitete Skalierung (denken in Batches)3.Trennen der Entscheidungen von der Ausführung4.Wunschdenken5.Technische Schulden

mehr: hcp://improuv.com/en/blog/f%C3%BCnf-‐aspekte-‐der-‐firmenpoliJk-‐als-‐ursachen-‐f%C3%BCr-‐verschwendung

... und noch etwas ganz anderes ...

im Juli:

Documents

AgileWelt · Test-driven development (TDD) eXtreme Programming (XP) Lean development ... KentBeck&und&Erich&Gamma:&JUnit Testgetriebene Entwicklung 173 Robert Martin hat in seinem