Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert,

Größe: px

Ab Seite anzeigen:

Download "Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de"

Hertha Braun
vor 8 Jahren
Abrufe

1 Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert,

2 Über mich Martin Lippert Senior IT-Berater bei akquinet it-agile GmbH Schwerpunkte: Agile Softwareentwicklung seit über 8 Jahren Refactoring Eclipse-Technologie und OSGi AOP Spring 2

de Schwerpunkte: Agile Softwareentwicklung seit über

3 Über die Firma, für die ich arbeite akquinet it-agile GmbH (im Verbund der akquinet AG) Fokussiert auf agile Softwareentwicklung Beratung Coaching Seminare und Trainings Projektmanagement Individual-Entwicklung 3

Softwareentwicklung Beratung Coaching Seminare und

4 Über agile Softwareentwicklung We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. See 4

comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

5 Was denkt die Welt? Inzwischen gehören agile Methoden in der Softwareentwicklung zum etablierten Standard 5

6 2005: Standish-Group: Chaos-Report 6

7 Was denkt die Welt? Trotzdem wird man manchmal angesehen, was wenn man vom Mars stammen würde 7

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? 8

Das sagt doch nichts aus. Hohe Transparenz?

9 Simple Things First Standup- bzw. Scrum-Meetings Continuous Integration Collective Ownership Refactoring Short Release Cycles Test-Driven Development Pair Programming Retrospective 9

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 10

Unternehmen steigen auf agile Methoden um Misserfolge: Projekte können

11 Wir erinnern uns Agile Softwareentwicklung bedeutet, Verantwortung zu übernehmen Kunde, Fachbereich: Geschäftswert Entwicklung: Technologie 11

12 überfordert viele Kunden Welcher Kunde oder Fachbereich kann seriös den Business Value einzelner Features einer Software berechnen und dann noch vorher? Welche Kunde schafft eine fachlich sinnvolle Projektplanung, die Einzel-Releases sinnvoll ordnet? These: Agile Projekte bieten den Kunden Möglichkeiten, mit denen die Kunden häufig gar nichts anfangen können. 12

Welche Kunde schafft eine fachlich sinnvolle Projektplanung, die Einzel-Releases sinnvoll

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 13

stabil aufrecht zu erhalten These: Es gibt in Unternehmen nur

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 14

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 15

dem Anwender tatsächlich hilft Die Qualität wird häufig als nicht wichtig

16 Warum ist das so schwer? Wir produzieren täglich Legacy-Code Was 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? 16

oder veraltet sein (das ist ganz normal) Ich muss mir die Fragen stellen: Kann

17 Wie können wir weiterkommen? 17

18 Die Henry-Ford-Episode 18

19 19

20 Eat Your Own Dogfood Henry Ford: Jedes Unternehmen muss soviel Wasser flussaufwärts einleiten, wie es flussabwärts entnimmt. 20

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 21

22 Qualitätszyklen reduzieren Regelungsbedarf und vereinfachen damit Prozesse. Beispiele Verantwortung für Wartung im Entwicklungsteam belassen. 22

23 Einfache und komplexe Lösungen Eine Erklärung 23

24 Philosophie Was gesagt werden kann, kann auch einfach gesagt werden. Wittgenstein 24

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 25

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 26

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 27

28 Harte Herausforderungen Diejenigen Features implementieren, die Business Value erzeugen und 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 28

29 Aber: Es lohnt sich!!! Vielen Dank. Martin Lippert akquinet it-agile GmbH 29

30 Bei Fragen rund im agile Softwareentwicklung 30

Ähnliche Dokumente

ZuuL - Entwicklung eines Adventures

ZuuL - Entwicklung eines Adventures im Rahmen der Uni-Tage 2009 Team 120 Universität Hamburg 16./17. November 2009 Team 120 (Universität Hamburg) ZuuL - Entwicklung eines Adventures 16.11.09 1 / 21 Übersicht