1. KEGON 2011 Die Quadratur des Kreises oder: Warum SCRUM CMMI-Level 5 erfüllt Dr. Thorsten Janning OOP, 25.01.2011

5. Hilft bei der aktiven IT-Governance

6. Natürlicher Konflikt zwischen Process Owner und Product Owner

7. Die Organisation neigt allerdings zu „Fett-Pölsterchen“ durch Stabs-AufgabenKEGON 2011 Seite 4

8. Typische Meinungen in einem durchschnittlichen Projekt Die Softwarequalität ist einfach zu schlecht! Die Spezifikation ist nie fertig! Der Test ist unsystematisch! Die Abnahme wird unberechtigt verweigert! Die Entwickler werden nicht effizient eingesetzt! ….. KEGON 2011 Seite 5

9. Der Gegenentwurf: SCRUM - Übersicht KEGON 2011 Seite 6

10. Agile Prinzipien Frühzeitig und durchgängig SW an den Kunden liefern Sich ändernde Anforderungen sind zu begrüßen Liefere funktionierende Software häufig Direktes Gespräch zwischen/innerhalb Teams Richte Projekte passend für motivierte Individuen ein Fachmitarbeiter und Entwickler arbeiten immer zusammen Funktionierende SW ist das wichtigste Maß für Fortschritt Stetiges Augenmerk für Güte und gutes Design Schlichtheit ist unerlässlich (vermeide Überflüssiges!) Die besten Ergebnisse kommen von selbst organisierenden Teams Das Team optimiert regelmäßig selbst sein Vorgehen. KEGON 2011 Seite 7

11. Agil und Qualität – ein Zielkonflikt? Traditionelles Anforderungs- und Qualitätsmanagement scheint doch agiler Entwicklung zu widersprechen…..ODER???? Prozesse und Kontrolle Anforderungsmanager lieben Dokumentation Anforderungsmanager wollen ausführliche geschriebene Spezifikationen sehen … Agile Entwicklung verändert das Anforderungs- und Qualitätsmanagement radikal…. Dauernde Repriorisierung von Tickets Keine ausführlichen Spezifikationen Die ständige Kommunikation mit dem Auftraggeber ist Anforderungsmanagement „bytheway“ KEGON 2011 Seite 8

12. Erfahrungen mit agilen Verfahren Projekte befragt nach der Umstellung auf Agil 1) : 95% Keine Zunahme der Kosten (oder gar Kostenreduzierung) 93% Produktivität besser oder wesentlich besser 88% Qualität besser oder wesentlich besser 83% Erfüllung der Geschäftsziele war besser oder wesentlich besser Untersuchung von agilen Projekten nach der Umstellung 2) : Kosten wurden um 57% verringert, verglichen zu anderen IT Lösungen für ähnlich komplizierte Projekte Aufwand, einschließlich eigener Entwicklung und vorher eingestellten Beratern, wurde im Vergleich zu alternativen Lösungen um 62% verringert Kritische Mängel wurden um beinahe 80% verringert Mängel insgesamt wurden um mehr als 60% verringert 1) Quelle: ShineTech, 2003 2) Quelle: Forrester Research, 2004 KEGON 2011 Seite 9

13. Einflussfaktoren für Qualitätsfähigkeit einer Organisation Entwicklung hochqualitativer Software ist von mehreren Parametern der AE-Organisation abhängig Agilität Die Reifegrade nach CMMI betrachten die Prozess-Professionalisierung einer Organisation mit dem wesentlichen Ziel der Qualitätsverbesserung Die Agilität von Entwicklungsteams hat für die optimale Ausrichtung der Qualität andere Optimierungskriterien Normales Agiles Projekt Klassisches Prozess-organisiertes Projekt Reifegrade nach CMMI KEGON 2011 Seite 10

14. …dann kann es doch eigentlich kein Widerspruch sein! Agilität ? Gibt es diese Kombination oder ist es die Suche nach der Quadratur des Kreises? Normales Agiles Projekt Klassisches Prozess-organisiertes Projekt Reifegrade nach CMMI KEGON 2011 Seite 11

15. Wie ist die Korrelation zwischen Qualität und Prozessorganisation? Studie: Welche Projekte sind die erfolgreichsten? Die mit einer ausgefeilten Prozessorganisation oder die ohne? KEGON 2011 Seite 12 Die Projekte mit ausgereiften Prozessen und Vorgehensmodellen sind erfolgreicher als die ohne! Die erfolgreichsten Projekte sind die, in denen die Projektverantwortlichen bereit und in der Lage sind, sich über die Prozesse hinwegzusetzen!

16. ...ein genauerer Blick auf die CMMI-Reifegrade Das sind doch unsere agilen Qualitätsprinzipien! KEGON 2011 Seite 13

17. Die Management-Theorie: Duale Prozess-Sicht Überraschung, Prinzip Person, Entscheidung, Verantwortung Wiederholung, Regel Skillprofil Automatisierung dynamisch strukturiert Quelle: Dr. Gerhard Wohland Matthias Wiemeyer Denkwerkzeuge für dynamische Märkte Verlagshaus Monsenstein und Vannerdat OHG Münster www.mv-wissenschaft.com Problem (z.B. Kunden- Anforderung) Jeder Arbeitsprozess wird durch ein Problem angestoßen und durch seine Lösung beendet. Bei trägen Problemen wird der Prozess fast ausschließlich durch Ereignisse getriggert, die sich wiederholen. Der Anteil überraschender Probleme ist gering. Die Prozessbeschreibung kann sich auf die Struktur beschränken. Seite 14 KEGON 2011

18. Software-Entwicklung als dynamisches Problem Überraschung Prinzip Person Entscheidung Verantwortung Wiederholung Regel Skillprofil Automatisierung Dynamischer Teil 1 2 3 4 Strukturierter Teil Bei dynamischen Problemen wird der Prozess vor allem durch überraschende Ereignisse getriggert. Die Behandlung einer Überraschung erfordert Ideen auf der Basis von Prinzipien. Nur motivierte und qualifizierte Menschen können mit Überraschungen sinnvoll umgehen. Seite 15 KEGON 2011

20. Regeln

21. Fleiß

22. Verhalten

24. Prinzipien

25. Idee

26. Werte

27. Führung

28. Jedes Problem ist eine Mischung aus strukturierten und dynamischen Anteilen.

29. Dynamik steigert den dynamischen Anteil vieler Projekte und sie ist heute eine der häufigsten Havarie-Ursachen für die Überlastung von methodisch geführten Projekten.

30. Die bewährten Methoden für strukturierte Projekte sind für dynamische Probleme keine Lösungen und wenn sie als Ersatz für dynamische Lösungen fungieren sollen, schaden sie sogar, weil sie wertvolle Zeit verschwenden. Seite 16 KEGON 2011

32. Zur Lösung dynamischer Probleme wird „Können“ notwendig, das auf Erfahrung, Prinzipien und Werten basiertErfahrung & Wissen (bilden eine) Erwartung (dass eine) Handlung (die Erwartung erfüllt) (Ergebnis ist) Enttäuschungoder Überraschung Bestätigung Irritation Nächste Regel Ideen (für neues Handeln) Theorie (als Filter) Seite 17 KEGON 2011

34. Für einen Erfolg in dynamischer Umgebung ist eine Werte-Kultur die unverzichtbare Basis. Seite 18 KEGON 2011

35. Werkzeug: Team als ein „widerständiges Nest“ permanent temporär Projektorganisation Linienorganisation Lenkungs- ausschuss Lieferanten Führung Projektleiter Projektteam Auftraggeber TPL-Runde Fachabteilung Teilprojekt Konsens- Werkstatt Produktion Teilprojekt Niederlassung Teilprojekt Elemente und Strukturen des „widerständigen Nests“ Seite 19 KEGON 2011

37. Wie definiert man :„Definition ofDone“

38. Wie integrieren wir unsere SCRUM-Teams in die herkömmliche Entwicklungs-organisation?

39. Wie migriert man die Mannschaft?

40. …..Agilität ? Normales Agiles Projekt Klassisches Prozess-organisiertes Projekt Reifegrade nach CMMI KEGON 2011 Seite 20

42. Alle Team arbeiten in synchronen Sprints

43. Und wie synchronisieren die Teams ihre Ergebnisse ?KEGON 2011 Seite 21

45. Neben Produktverantwortlichen gibt es Prozessverantwortliche

46. Anforderungsmanagement

47. QS

48. Releasemanagement

49. SCRUM-Teams

50. Für Fachkomponenten

53. Integration von SCRUM-Teams in die Organisation - Releaseplanung Releases als Synchronisationspunkte KEGON 2011 Seite 24

54. Abbildung auf V-Modell und Quality Gates Seite 25 Auftraggeber, Stakeholder, etc. Auftraggeber ProdOwner The Missing Gap? Software-Entwicklung SCRUM Team KEGON 2011

56. Der Architekturdurchstich ist die Schwelle zur dynamischen Entwicklung

58. SprintBacklog Scrum Meeting Retrospektive Vision Sprint ProductBacklog Task Board Review Meeting „Fertiges“ Produkt Die Vorarbeiten zum ersten Sprint KEGON AG 2011 Seite 28

59. Definition of Done Deployment Der Code inklusive der zugehörigen automatischen Tests ist eingecheckt Er wurde mit dem aktuellen Stand von EASY erfolgreich übersetzt und auf dem Buildserver installiert. Test Die Akzeptanzkriterien sind in Form von Testfällen für Design und Funktion definiert Die Tests sind möglichst vollständig (bis auf GUI-Tests) automatisiert. Die automatischen und die manuellen Tests wurden auf dem Buildserver fehlerfrei durchgeführt Dokumentation Der Code ist vollständig mit Inline-Kommentaren versehen. Wesentliche Konzepte sind zusätzlich in geeigneter Form dokumentiert. KEGON 2011

61. Thema/Inhalt sollte :

62. notleidend bzgl. Reaktionsgeschwindigkeit der Entwicklung und

63. von zentraler Bedeutung für den Kunden sein.

64. Initiales Team sollte hochmotiviert und nach Möglichkeit mit Fach und Architektur vertraut sein.

65. Mindestens drei bis vier Sprints für das „Einrütteln“ mit den Initialen Teams

67. KEGON 2011 Seite 32 Kontakt Noch Fragen offen? Schauen Sie doch mal ins Web unter www.kegon.de Oder fragen Sie einfach bei mir nach: thorsten.janning@kegon.de