Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Was funktioniert und was nicht?Agile Softwareentwicklung in der PraxisMartin Lippert, [email protected]
2
Über mich
Martin LippertSenior IT-Berater bei akquinet it-agile GmbH
Schwerpunkte:Agile Softwareentwicklung seit über 8 Jahren
Refactoring
Eclipse-Technologie und OSGi
AOP
Spring
3
Über die Firma, für die ich arbeite
akquinet it-agile GmbH (im Verbund der akquinet AG)
Fokussiert auf agile SoftwareentwicklungBeratung
Coaching
Seminare und Trainings
Projektmanagement
Individual-Entwicklung
http://www.it-agile.de
4
Über agile Softwareentwicklung
„We are uncovering better ways of developing software bydoing it and helping others do it. Through this work we havecome to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items on the right, we valuethe items on the left more.“
See http://www.agilemanifesto.org/
5
Was denkt die Welt?
Inzwischen gehören agile Methoden in der Softwareentwicklung zum etablierten Standard
6
2005: Standish-Group: Chaos-Report
7
Was denkt die Welt?
Trotzdem wird man manchmal angesehen, was wenn man vom Mars stammen würde…
8
Der Blick in verwirrte Gesichter - Auszüge
Tägliches Deployment?„Völlig undenkbar für unser Unternehmen.“
Tägliche Fortschrittskontrolle?„Das sagt doch nichts aus.“
Hohe Transparenz?„Um Gottes Willen, dann merkt mein Chef ja sofort,wenn etwas nicht gut läuft.“
Pair Programming?„Ohne mich!“
Tests zuerst schreiben?„Wie soll das denn gehen?“
…
9
Simple Things First
Standup- bzw. Scrum-Meetings
Continuous Integration
Collective Ownership
Refactoring
Short Release Cycles
Test-Driven Development
Pair Programming
Retrospective
10
Erfolge und Misserfolge
Erfolge:Agile Projekte in klein und groß
Scrum sehr erfolgreich im Projekt-Management (auch großer Projekte)
Ganze Unternehmen steigen auf agile Methoden um
Misserfolge:Projekte können trotzdem scheitern
Sind agile Methoden daran schuld?
Kultur-Wandel sind schwierig
11
Wir erinnern uns…
Agile Softwareentwicklung bedeutet, Verantwortung zu übernehmen
Kunde, Fachbereich: Geschäftswert
Entwicklung: Technologie
12
…überfordert viele Kunden
Welcher Kunde oder Fachbereich kann seriös den Business Valueeinzelner Features einer Software berechnen – und dann noch vorher?
Welche Kunde schafft eine fachlich sinnvolle Projektplanung, dieEinzel-Releases sinnvoll ordnet?
These: Agile Projekte bieten den Kunden Möglichkeiten, mit denen die Kunden häufig gar nichts anfangen können.
13
…überfordert viele Entwickler
schnell Features realisieren
gleichzeitig eine hohe Qualität abliefern
über eine lange Zeit stabil aufrecht zu erhalten
These: Es gibt in Unternehmen nur wenige Teams, die alle drei Punkte gleichzeitig umsetzen können
14
Es ist unglaublich schwer…
In kleinen Inkrementen stetig Business Value zu erzeugen
Die Qualität durchgehend hoch zu halten
Und:Das über einen langen Zeitraum aufrecht zu erhalten
15
Warum ist das so schwer?
Wir interessieren uns nicht dafür, ob die Software wirklich einsetzbar ist und dem Anwender tatsächlich hilft
Die Qualität wird häufig als nicht wichtig empfunden
Was nach einem „Projektende“ kommt, spielt oft keine Rolle
Gleichzeitig tendieren wir zu:Komplexen Lösungen
Komplexen Technologien
16
Warum ist das so schwer?
Wir produzieren täglich Legacy-CodeWas ich heute implementiere, kann morgen falsch oder veraltet sein (das ist ganz normal)
Ich muss mir die Fragen stellen:Kann jemand anders meinen Code lesen und verstehen? Auch noch in fünf Jahren?
Kann mein Code auch in Zukunft noch leicht verändert und anpasst werden?
17
Wie können wir weiterkommen?
18
Die Henry-Ford-Episode
19
20
Henry Ford: „Jedes Unternehmen muss soviel Wasser flussaufwärts einleiten, wie es flussabwärts entnimmt.“
Eat Your Own Dogfood
21
Eat Your Own Eclipse
Das Eclipse-Team hat den Vorteil, dass es eine Entwicklungsumgebung implementiert
Es benutzt Eclipse, um Eclipse zu entwickeln
Das Ergebnis: Beeindruckend hohe Qualität
22
…und vereinfachen damit Prozesse.
Beispiele
Verantwortung für Wartung im Entwicklungsteam belassen.
…
Qualitätszyklen reduzieren Regelungsbedarf
23
Einfache und komplexe Lösungen – Eine Erklärung
24
„Was gesagt werden kann, kann auch einfach gesagt werden.“
Wittgenstein
Philosophie
25
Na und?
Was soll daran so schwer sein?
“It's easy to have a complicated idea. It's very very hard to have a simple idea.” -- Carver Mead
Bedenke:Simple? -> JA
Easy? -> NEIN
26
Einfachheit anstreben
Hindernislisten an der Wand
Kaizen / Babysteps
Qualitätszyklen
Wie muss das Problem / der Kontext aussehen, damit die Lösung einfach wird?
Vertrauen statt Kontrolle
Ggf. etablierte und erprobte Technologie einsetzen
Sich den Gegenwind um die Nase wehen lassen
27
Weiche Herausforderungen
Kritikfähig sein und Kritik konstruktiv üben können
Im Team arbeiten und seine eigenen Lösungen in Frage stellen
Respekt gegenüber anderen und deren Lösungen
Den eigenen Entwicklungsprozess…Überdenken
In Frage stellen
Verbessern
Gesund erhalten
28
Harte Herausforderungen
Diejenigen Features implementieren, die Business Value erzeugenund nicht diejenigen, die vielleicht am meisten Spaß machen
Eine Architektur realisieren, die sich einfach ändern lässt
Nicht nur ein System implementieren, „das läuft“, sondern eines, welches sich über Jahre hinweg weiterentwickeln und verändern lässt
Einfache Lösungen
Softwaretechnische Design-Prinzipien wie SOC, DRY, DIP, etc. sicher beherrschen und einsetzen
30
Bei Fragen rund im agile Softwareentwicklung