10 Jahre Agil

1,649 views

Published on

Präsentation auf der SEE 2007-Konferenz: Was hat sich in den letzten 10 Jahren im agilen Umfeld getan? Was kommt noch?

Die Folien als PDF gibt es per E-Mail: info@it-agile.de

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,649
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

10 Jahre Agil

  1. 1. 10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock [email_address]
  2. 2. Hintergrund 1/2 <ul><li>Senior IT-Berater bei der akquinet AG </li></ul><ul><li>eXtreme Programming seit Anfang 1999, dann Scrum und FDD dazu </li></ul><ul><li>Kommerzielle Projekte </li></ul><ul><ul><li>2 bis 30 Entwickler, 11 Wochen bis 5 Jahre </li></ul></ul><ul><li>Große Erfolge ... </li></ul><ul><ul><li>sehr kurze Projektlaufzeiten </li></ul></ul><ul><ul><li>Software mit hohem Nutzen für Anwender und Unternehmen </li></ul></ul><ul><ul><li>engagierte Entwickler </li></ul></ul><ul><ul><li>exzellente Planbarkeit und Controlling </li></ul></ul>
  3. 3. Hintergrund 2/2 <ul><li>... und herbe Rückschläge </li></ul><ul><ul><li>degenerierter Code, Strukturverlust der Architektur, steile Aufwandskurve </li></ul></ul><ul><ul><li>Umfeld nicht bereit </li></ul></ul><ul><ul><li>Kunde mit seiner geänderten Rolle überfordert </li></ul></ul><ul><ul><li>Risikobereitschaft als Bumerang </li></ul></ul>
  4. 4. Timeline 1/4 1996 1997 1998 C3-Projekt beginnt XP Begriff XP zum ersten Mal in der Öffentlichkeit (OOPSLA) Ward Cunningham: EPISODES 1995 Smalltalk- Refactoring- Browser 1986: Scrum Umfeldfragen ungeklärt: Festpreise, große Projekte, … Coad / De Luca: FDD Crystal-Clear Die Mehrheit ist entsetzt!
  5. 5. Timeline 2/4 1999 2000 2001 „ eXtreme Programming explained“ 1. XP-Conference in Sardinien Agiles Manifest C3-Projekt beendet SCRUM-Buch ASD-Buch Cockburn: Agile Software Development Kerth: Project Retrospectives Beck: „80% XP bringt nur 20% des Nutzens“ JUnit
  6. 6. Timeline 3/4 2002 2003 2004 Bücher, Bücher, Bücher Lean Software Development XP-Gurus treten in den Hintergrund Zweite Auflage „eXtreme Programming explained“ FDD-Buch V-Modell XT The Eclipse Way Jeder ist agil. Sabre: 42% produktiver, nur noch 20% der Fehler
  7. 7. Timeline 4/4 2005 2006 2007 Standish Group empfiehlt agile Methoden JAX-Konferenz mit Agility Day Unittesting in Groovy integriert Jede Java-IDE enthält JUnit & Refactorings Umfeldfragen im Wesentlichen geklärt SAP macht Scrum Microsoft macht Scrum Google entwickelt agil
  8. 8. 2005: Standish-Group: Chaos-Report
  9. 9. Diskussionsschwerpunkte 1999 2007 Technik (Unit-Testen, Refactoring…) Management (Tracking, Schätzen…) Kundenrolle (Nutzenorientierung, Planung)
  10. 10. Die Verantwortlichkeiten… 1. Anforderungen 2. Aufwandsschätzung 3. Priorisierung 4. Funktionalitäten Verantwortlich für Geschäftswert Kunde Verantwortlich für Technologie Entwickler
  11. 11. …überfordern viele Kunden <ul><li>Mit „agil“ können kurze Releasezyklen realisiert werden. </li></ul><ul><li>Damit kann der Kunde schnell Nutzen aus seinen Investitionen ziehen. </li></ul><ul><li>Welcher Kunde kann Nutzen seriös berechnen – und dann noch vorher? </li></ul><ul><li>Welcher Kunde schafft eine fachlich sinnvolle Projektplanung, die Einzelreleases sinnvoll ordnet? </li></ul>Verantwortlich für Geschäftswert Kunde These: Agile Projekte bieten den Kunden Möglichkeiten, mit denen die Kunden gar nichts anfangen können.
  12. 12. …überfordern viele Teams <ul><li>Teams sollen den Entwicklungsprozess selbst anpassen. </li></ul><ul><li>Dazu ist ständige selbstkritische Reflektion über die eigene Arbeit notwendig. </li></ul><ul><li>Arbeit wird ständig (minimal) reorganisiert. </li></ul><ul><li>Agile Techniken wie inkrementeller Entwurf, testgetriebene Entwicklung sind sehr anspruchsvoll. </li></ul>Verantwortlich für Technologie Entwickler These: Viele Entwicklungsteams nehmen den Entwicklungsprozess nicht in Verantwortung.
  13. 13. Was wir wirklich brauchen! <ul><li>Der Kunde braucht professionelle Unterstützung, um seine Rolle in agilen Projekten wahrzunehmen. </li></ul><ul><li>Einen Quantensprung schaffen wir nur, wenn wir dem Kunden dort methodische Unterstützung bieten können. </li></ul><ul><li>Entwicklungsteam müssen lernen, ihren Entwicklungsprozess selbst anzupassen. </li></ul>
  14. 14. Diskussionsschwerpunkte 1999 20XX Technik (Unit-Testen, Refactoring…) Management (Tracking, Schätzen…) Kundenrolle (Nutzenorientierung, Planung) Organisation von Unternehmen
  15. 15. Fazit <ul><li>Gut, dass es agile Methoden gibt. </li></ul><ul><li>Positive Einflüsse der agilen Methoden untereinander und auf reichhaltige Methoden. </li></ul><ul><li>„ Agil“ entwickelt sich weiter, wird aber auch „unschärfer“. </li></ul><ul><li>„ Agil“ bedeutet immer noch harte Arbeit und umdenken (XP mehr als Scrum). </li></ul><ul><li>Die Potenziale von „agil“ werden kaum ausgenutzt. </li></ul><ul><li>„ Agil“ betrifft neben Entwicklern auch Manager, Kunden und Anwender. </li></ul>
  16. 16. Schluss-Satz <ul><li>„ In zwanzig Jahren wird man über Wasserfall-Integration und Arbeiten ohne Refactoring lächeln, wie wir heute über Compiler lächeln, die Nachts im Batch laufen.“ </li></ul><ul><li>(Vermutung Jens Coldewey) </li></ul>
  17. 17. <ul><li>Noch Fragen? </li></ul>Vielen Dank für die Aufmerksamkeit

×