• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Warum Scrum CMMI Level 5 erfüllt
 

Warum Scrum CMMI Level 5 erfüllt

on

  • 1,055 views

 

Statistics

Views

Total Views
1,055
Views on SlideShare
1,055
Embed Views
0

Actions

Likes
0
Downloads
22
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Warum Scrum CMMI Level 5 erfüllt Warum Scrum CMMI Level 5 erfüllt Presentation Transcript

    • KEGON 2011
      Die Quadratur des Kreises
      oder:
      Warum SCRUM CMMI-Level 5 erfüllt
      Dr. Thorsten Janning
      OOP, 25.01.2011
    • Agilität und Prozesse: Alternative,Tabubruch, oder was?
      Quelle: SQS
      KEGON 2011
      Seite 2
      • Über Jahre haben wir Vorgehens- und Prozessmodelle propagiert,
      • jetzt kommen die Propheten der Agilität und alles soll anders sein?…
    • Die Prozess-Reifegrade von CMMI im Überblick
      KEGON 2011
      Seite 3
    • Der prozessorientierte Organisationsansatz
      IT-Planung
      Anford.-Mgmt
      Betriebskoord.
      Entwicklungssteuerung
      2nd Level
      Arch
      RelM
      AM
      PrdM
      RelM
      AM
      QS&TstM
      Rollout
      ArcM
      QS&TstM
      Projektmanagement/Koordination
      Entwicklung(Test)
      IT-Betrieb
      Dienstleistungen
      Gewerke
      DL-Mgmt
      produktbezogen jeweils innerhalb einer Org-Einheit
      • Sehr bewährt für komplexe Anwendungslandschaften
      • Hilft bei der aktiven IT-Governance
      • Natürlicher Konflikt zwischen Process Owner und Product Owner
      • Die Organisation neigt allerdings zu „Fett-Pölsterchen“ durch Stabs-Aufgaben
      KEGON 2011
      Seite 4
    • 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
    • Der Gegenentwurf: SCRUM - Übersicht
      KEGON 2011
      Seite 6
    • 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
    • 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
    • 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
    • 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
    • …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
    • 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!
    • ...ein genauerer Blick auf die CMMI-Reifegrade
      Das sind doch
      unsere agilen
      Qualitätsprinzipien!
      KEGON 2011
      Seite 13
    • 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
    • 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
    • Agile Management-Werkzeuge
      Arbeitsbereich
      der Projektführung
      dynamisch
      komplex
      Trend
      strukturiert
      Arbeitsbereich
      des Projektverwaltens
      Strukturierte Werkzeuge
      • Methode
      • Regeln
      • Fleiß
      • Verhalten
      • Steuerung
      Komplexe Werkzeuge
      • Theorie
      • Prinzipien
      • Idee
      • Werte
      • Führung
      • Jedes Problem ist eine Mischung aus strukturierten und dynamischen Anteilen.
      • 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.
      • 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
    • Die unterschiedlichen Wege zur Problemlösung
      Theorie basiert
      Methoden basiert
      • Irritation eröffnet den Zugang zu neuen Erkenntnissen und Handlungsmöglichkeiten
      • Zur Lösung dynamischer Probleme wird „Können“ notwendig, das auf Erfahrung, Prinzipien und Werten basiert
      Erfahrung & 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
    • „Kulturarbeit“ als Management-Aufgabe
      Verhaltens-Kultur
      (tayloristisch, strukturiert)
      Werte-Kultur
      (post-tayloristisch, dynamisch)
      Vereinbarung, Pünktlichkeit,
      Höflichkeit, Korrektheit,...
      Vertrauen/Misstrauen
      Achtung/Missachtung
      Liebe/Hass,…
      Verhalten (Tun)
      Werte

      besteht aus:
      Argument, Anweisung,
      Drohung, Belohnung, Strafe,…
      Idee, Erkenntnis, Ereignis
      Erfahrung, Vorbild,…
      Steuerung
      (strukturiert)
      Führung

      wird erzeugt
      durch:
      • Für tayloristischeOrganisationen reicht eine Verhaltens-Kultur.
      • Für einen Erfolg in dynamischer Umgebung ist eine Werte-Kultur die unverzichtbare Basis.
      Seite 18
      KEGON 2011
    • 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
    • …einige praktische Fragen
      • Wie organisieren wir Arbeits-teilung auf mehrere Teams?
      • Wie definiert man :„Definition ofDone“
      • Wie integrieren wir unsere SCRUM-Teams in die herkömmliche Entwicklungs-organisation?
      • Wie migriert man die Mannschaft?
      • …..
      Agilität
      ?
      Normales
      Agiles Projekt
      Klassisches
      Prozess-organisiertes
      Projekt
      Reifegrade
      nach CMMI
      KEGON 2011
      Seite 20
    • Divide et impera!
      • Wir teilen das große Team in mehrere kleine Teams und lassen diese agil arbeiten!
      • Alle Team arbeiten in synchronen Sprints
      • Und wie synchronisieren die Teams ihre Ergebnisse ?
      KEGON 2011
      Seite 21

    • Iterationen
      Fach-
      Fach-
      prozess2
      Fach-
      Prozess 1
      • Variante 1: Prozesse für SCRUM-Teams
      • Neben Produktverantwortlichen gibt es Prozessverantwortliche
      • Anforderungsmanagement
      • QS
      • Releasemanagement
      • SCRUM-Teams
      • Für Fachkomponenten
      • Für Infrastrukturkomponenten
      Framework
      Auftraggeber
      Organisation mehrerer selbständiger Teams
      Inbetriebnahme
      Betrieb
      Kundenbezogene
      Kommunikation
      KEGON 2011
      Seite 22
      • Variante 2: SCRUM of SCRUM
      • Team von Teamsprechern organisiert sich im SCRUM
    • Es gibt sie doch: Die Quadratur des Kreises (fast )
      Entwicklung hochqualitativer Software ist von mehreren Parametern der AE-Organisation abhängig
      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 für große und kleine Teams unterschiedliche Optimierungskriterien
      Die Optimierung auf der Qualitätsskala ist für kleine Teams anders als für sehr große Teams
      Für große und verteilte Teams kann man u.a. Werkzeuge für dynamische Prozesse zur Steuerung einsetzen
      Scrum of Scrum
      Agil
      Prozess-optimiertes
      Projekt
      Agilität
      Normales
      Agiles Projekt
      Klassisches
      Prozess-organisiertes
      Projekt
      Größe und
      Verteilung
      Reifegrade
      nach CMMI
      KEGON 2011
      Seite 23
    • Integration von SCRUM-Teams in die Organisation - Releaseplanung
      Releases als Synchronisationspunkte
      KEGON 2011
      Seite 24
    • Abbildung auf V-Modell und Quality Gates
      Seite 25
      Auftraggeber,
      Stakeholder,
      etc.
      Auftraggeber
      ProdOwner
      The Missing Gap?
      Software-Entwicklung
      SCRUM Team
      KEGON 2011
    • Generelle Vorgehensweise in großen Projektkontexten
      KEGON AG 2011
      Seite 26
      • Architekturen und generische Modelle sind stabile und strukturierte Elemente des Prozesses
      • Der Architekturdurchstich ist die Schwelle zur dynamischen Entwicklung
      • SCRUM ist das ideale Werkzeug zur Beherrschung der Dynamik in Prozessen
    • Der Rahmen für agile Entwicklung
      KEGON AG 2011
      Seite 27
      Gesudheit
      Generische Prozesse
      Software-Architektur
      Datenmodell
    • SprintBacklog
      Scrum
      Meeting
      Retrospektive
      Vision
      Sprint
      ProductBacklog
      Task Board
      Review
      Meeting
      „Fertiges“ Produkt
      Die Vorarbeiten zum ersten Sprint
      KEGON AG 2011
      Seite 28
    • 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
    • Migration der Mannschaft
      KEGON 2011
      Seite 30
      • Einführen des SCRUM-Verfahrens mit einem oder wenigen Teams
      • Thema/Inhalt sollte :
      • notleidend bzgl. Reaktionsgeschwindigkeit der Entwicklung und
      • von zentraler Bedeutung für den Kunden sein.
      • Initiales Team sollte hochmotiviert und nach Möglichkeit mit Fach und Architektur vertraut sein.
      • Mindestens drei bis vier Sprints für das „Einrütteln“ mit den Initialen Teams
      • Ausweiten des Verfahrens mit Aufteilen des/der initialen Teams für nachfolgende Sprints
    • Summary
      Eine reife Prozessorganisation erzeugt Qualität
      Die Qualität wird „von oben“ organisiert und kontrolliert
      Es ist bewiesen: Qualität in agilen Teams kommt „von innen“, ist effizient und nachhaltig
      Agile Prinzipien entsprechen dem höchsten CMMI-Reifegrad
      Agile Teams sind in Größe und Verteilung zunächst beschränkt
      Große Projekte sind ebenfalls zu agilisieren
      Grundidee ist die Aufteilung in mehrere SCRUM-Teams
      Die Organisation von Teams kann nach Prozessreife-Maßnahmen und schließlich sogar als SCRUM of SCRUM geschehen
      Dazu können Werkzeuge für dynamische Prozesse genutzt werden
      KEGON 2011
      Seite 31
    • 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