Agile Entwicklung Technical Literacy 1 Prof. Dr.-Ing. Carsten Bormann cabo@tzi.org 1
geek & poke Oliver Widder 2
How Programs Are Usually Written The requirements specification was defined like this The developers understood it in that way This is how the problem was solved before. This is how the problem is solved now That is the program after debugging This is how the program is described by marketing department This, in fact, is what the customer wanted ;-) 3
xkcd 844 } Thanks, Randall Munroe, for all the wonderful teaching materials
5
Most software projects fail Failure Challenges Success 60,0 45,0 30,0 15,0 0,0 1994 1996 1998 2000 2002 2004 2009 (Standish CHAOS reports) 6
Most software projects fail Abandoned Schedule Overrun Good Budget overrun OK Sauer, Gemino, Reich, CACM Nov 2007: IT projects perform far better than is popularly believed. 7
Building the thing right vs. Building the right thing
9
agilemanifesto.org Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 10
agilemanifesto: Principles (1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. 11
agilemanifesto: Principles (2) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is faceto-face conversation. Working Agile software is the primary measure of progress. processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 12
agilemanifesto: Principles (3) Continuous attention to technical excellence and good design enhances agility. Simplicity the art of maximizing the amount of work not done is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 13
Agile Development Agile Focus Agile Collaboration Agile Feedback Agile Debugging Agile Coding 14
Agile Focus Work for outcome Customer Value pays the bills Justify Technology Use Let Customers make Decisions Activate tacit knowledge, avoid Process Confabulation Embrace Change! Use Short Iterations, Release in Increments Create Customer Value quickly! Get non-confabulated requirements Fixed Prices are Broken Promises 15
Agile Feedback Question until you understand Get Frequent Feedback Using Demos Keep it releasable Continuous Integration Automate Acceptance Testing a feature doesn't actually exist until tests prove that it works Use Short Iterations, Release in Increments Feel the Rhythm 16
Agile Coding Test First (Test-Driven Development) red/green/refactor Program Intently and Expressively (PIE clever) clean code is code that is pretty much what you would expect Communicate by Code comments are a code smell documents? customer developer developer developer presence future use an agile language! Keep it Simple 17
Agile Debugging Quick Fixes become Quicksand Keep Logs Report all Exceptions crash/log on bugs be robust to environmental problems Attack Problems in Isolation e.g., use mocks for unit testing Test-Driven Development Continuous Integration 18
Agile Collaboration Schedule Regular Face Time Standup Meeting: Announce Yesterday/Today/Obstacles Criticize Ideas, not People Invest in your Team Know when to unlearn Architects Must Write Code Practice Collective Ownership Review Code Keep Others Informed Teams must be sustainable 19
Agile Focus: Planning Game Iterationen, z.b. alle zwei Wochen; Inkremente Beginn: Planning Game Kunde: Story Cards für neue Funktionen Entwickler: Bewerten (Story Points) ggfs aufteilen Kunde sortiert was ist in der nächsten Iteration? begrenzt durch Anzahl Punkte weitergehende Planung möglich, bleibt flexibel Am Ende: Abgleich Planung/Realität Selbstreflexion und Adaption! z.b.: Punktesystem anpassen (Velocity) 20
TDD: Test-Driven Development Test schreiben Test ausführen TDD-Zyklus Refactoring Code schreiben Test ausführen Bild: Jan Krutisch 21
TDD: Test-Driven Development red/green/refactor Tests zwingen, frühzeitig über das API nachzudenken dokumentieren den Code geben Sicherheit beim Refactoring Work for Outcome: YAGNI (You Aren t Gonna Need It) Ping-Pong paßt hervorragend zur Paarprogrammierung (Driver-/Navigator-Paradigma) Es gibt immer noch Bugs, aber jeweils nur einmal Continuous Integration 22
Essentials: Prozesse und Tools Versionskontrolle Für alle Dokumente (Quelltext, Spezifikationen, Dokumentation) Automatischer Build-Prozeß Continuous Integration (gute Testabdeckung!) Manuelle Prozesse vermeiden oder regelmäßig üben Bug-Tracking Zero-Defect-Strategie Kommunikation: F2F + Lebendige Dokumente Minimale technische/organisatorische Barrieren Wiki Projektmanagement, Zeitplan User Stories; voll heruntergebrochene Aktivitäten (Tasks) Embrace Change! 23