agilewelt · test-driven development (tdd) extreme programming (xp) lean development ......
TRANSCRIPT
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
The Forrester Wave™: Agile Development Management Tools, Q2 2010 For Application Development & Delivery Professionals
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.
Source: Forrester Research, Inc. 56100
“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%
Quelle: The Forrester Wave. Develop Management Tools, Q2 2010
Forrester: zwei Zyklen treiben agiles Projektmanagement
© 2010, Forrester Research, Inc. Reproduction Prohibited May 5, 2010
The Forrester Wave™: Agile Development Management Tools, Q2 2010 For Application Development & Delivery Professionals
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.
Source: Forrester Research, Inc. 48153
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
Quelle: The Forrester Wave. Develop Management Tools, Q2 2010
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
AutomatisierterAkzeptanztest
AuslieferbarerCode
ATDD
CI
TDD
User Story
KundeProduct Owner
Akzeptanz-kriterien
AutomatisierterAkzeptanztest
AuslieferbarerCode
ATDD
CI
???
TDD
User Story
KundeProduct Owner
Akzeptanz-kriterien
AutomatisierterAkzeptanztest
AuslieferbarerCode
ATDD
CI
Strategische Planung
Inves,,onsentscheidungen
Produkte
Projekte
TDD
User Story
KundeProduct Owner
Akzeptanz-kriterien
AutomatisierterAkzeptanztest
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: