CMMI im Kontext von Agilität

Transkript

1 CMMI im Kontext von Agilität PMA, , Zug by mimacom ag

2 Zur Person David Krebs COO, Mitglied der Geschäftsleitung mimacom ag Software Engineer EMBA GM

3 mimacom ag facts and figures Gründung 1999 als Spin-Off der HTA Burgdorf Spezialisiert auf JEE/Java-Entwicklung ca. 70 Mitarbeiter in der Schweiz Initiator and Owner von div. Open Source Initiativen Fokus auf Standards in Entwicklung und Projektabwicklung ISO-9001:2011 nach TQM seit HERMES: HSPTP und HSPM SCRUM: Certified SCRUM-Master ITIL: Certified Foundation CMMI Scampi B September 2008 Level 3, Scampi A Level 5 geplant Q2/2012 Hauptsitz Bern, Geschäftsstellen in Zürich, Basel und Lausanne europaweite mimacom group mit ca. 120 Mitarbeitern

4 Agenda CMMI Referenzmodelle Aufbau am Beispiele CMMI-DEV Reifegrade und Appraisals in CMMI Praxisbeispiel im agilen Kontext

5 Familie von 3 Referenzmodellen Capability Maturity Model Integration «What»-Modelle Beurteilung und Verbesserung von konkreten Prozessmodellen (Reifegrade) Vorgabe von Zielen und Praktiken in Prozessbereichen («What») das «How» ist spezifisch und Ihnen überlassen 3 Referenzmodelle CMMI-DEV: Software- / Systementwicklung (Fokus hier) CMMI-ACQ: Software- / Systembeschaffung CMMI-SVC: Dienstleistungserbringung Integrative Implementierung der 3 Modelle durch Moularisierung

6 History 1986: Start im SEI Software Engineering Institute der Carnegie Mellon University in Pittsburgh, Owner von CMM/CMMI Initiative des US-Verteidigungsministeriums zur Entwicklung eines Systems zur Bewertung der Reife von Softwareprozessen 1991: CMM : CMMI Modularität und integrale Verwendung 2006: CMMI : CMMI-ACQ : CMMI-SVC : CMMI 1.3 für alle Modelle

7 Abgrenzung ISO-9001 CMMI-DEV ist kompatibel zu ISO 9001 CMMI bietet keine TQM (wie z. Bsp. TQMi) mehr Tiefe (konkrete Praktiken) ITIL CMMI-SRV kann grundsätzlich in allen Dienstleistungsorganisationen angewendet werden CMMI-SRV als Alternative zu ITIL für IT-Dienstleistungsorganisationen

8 Agenda CMMI Referenzmodelle Aufbau am Beispiele CMMI-DEV Reifegrade in CMMI Praxisbeispiel im agilen Kontext

9 Aufbau Process Area (PA) Required Specific Goals (SG) Generic Goals (GG) Expected Specific Practices (SP) Generic Practices (GP) Informative Example Work Products Purpose Statement Subpractices Introductory Notes Subpractices Related Process Areas Generic Practice Elaborations

10 Mengen CMMI-DEV 22 Process Areas (PA) ca. 60 Ziele 59 specific (SG) 3 generic (GG) ca. 180 Praktiken 165 specific (SP) 13 generic (GP) > 300 Unterpraktiken

11 REQM (Requirements Management) Kategorie: Project Management / Level: 2 Zweck The purpose of Requirements Management (REQM) is to manage requirements of the project s products and product components and to ensure alignment between those requirements and the project s plans and work products. Steht in Beziehung mit diesen Process Areas: Requirements Design / Technical System / Configuration Management / Project Monitoring and Control / Riskmanagement

12 REQM Ziele und Praktiken 1 Specific Goal SG 1 Manage Requirements Requirements are managed and inconsistencies with project plans and work products are identified. 5 Specific Practices SP 1.1 Understand Requirements SP 1.2 Obtain Commitment to Requirements SP 1.3 Manage Requirements Changes SP 1.4 Maintain Bidirectional Traceability of Requirements SP 1.5 Ensure Alignment Between Project Work and Requirements SP 1.1: Develop an understanding with the requirements providers on the meaning of the requirements

13 4 PA - Kategorien Category Process Management Project Management Engineering Support Process Areas Organizational Process Definition Organizational Process Focus Organizational Performance Management Organizational Process Performance Organizational Training Integrated Project Management Project Monitoring and Control Project Planning Quantitative Project Management Requirements Management Risk Management Supplier Agreement Management Product Integration Requirements Development Technical Solution Validation Verification Causal Analysis and Resolution Configuration Management Decision Analysis and Resolution Measurement and Analysis Process and Product Quality Assurance

14 Agenda CMMI Referenzmodelle Aufbau am Beispiele CMMI-DEV Reifegrade und Appraisals in CMMI Praxisbeispiel im agilen Kontext

15 2 Modelle für Reifegrade Capability Levels Misst die Leistungsfähigkeit der Prozesse in einer oder mehreren Processareas 4 Levels, Auswahl für Appraisals ist frei Basis ist die Implementierung der generischen Ziele und Praktiken Maturity Levels Misst den Reifegrad der Prozesse über die ganze Organisation 5 Levels, Auswahl gegeben durch das CMMI-Modell

16 Levels im Vergleich

17 Generische Ziele und Praktiken GG1: Achieve Specific Goals Die spezifischen Praktiken einer PA werden umgesetzt GG2: Institutionalize a Managed Process Geführte Prozesse (Beschreibung, Management, POs, Changemanagement, Policies, etc.) GG3: Institutionalize a Defined Process Tailoring, projektspezifische Anwendung Rückfluss der Erfahrungen in die Organisation und Continous Improvement

18 Capability Levels CL 3 Defined es gibt ein projektspezifisches Tailoring, angepasste Prozessausführung (GG 3) CL 2 CL 1 CL 0 Managed es gibt eine Unternehmenspolicy für die Prozesse, sie sind beschrieben, werden kontrolliert ausgeführt und reviewed (GG 2) Performed Prozessausführung ist vorhanden und wiederholbar (SGs), die Ausführung kann aber inkonsitent, nicht beschrieben, nicht kontrolliert sein (GG 1) Incomplete - Chaos oder unvollständige Umsetzung

19 Capability Levels Specific Goals and Practices Generic Goals and Practices SG 1 SG x GG 1 GG 2 GG 3 CL 3 Do CL2 and add GP 3.Xs SP 1.1 SP 1.2 SP... SP x.y GP 1.1 GP 2.1 GP... GP 2.10 GP 3.1 GP 3.2 CL 2 Do CL 1 and add GP 2.Xs SP 1.1 SP 1.2 SP... SP x.y GP 1.1 GP 2.1 GP... GP 2.10 CL 1 CL 0 Do ALL SGs & SPs, SP satisfying 1.1 GP 1.1 Do zero or more SPs, but not all SP 1.2 SP 1.2 SP... SP... SP x.y SP 2.3 GP

20 5 Maturity Levels (Reifegrade) 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed 1 Initial Level Focus Continuous Process Improvement Quantitative Management Process Standardization Basic Project Management Process Areas Causal Analysis and Resolution Organizational Performance Management Organizational Process Performance Quantitative Project Management Decision Analysis and Resolution Integrated Project Management Organizational Process Definition Organizational Process Focus Organizational Training Product Integration Requirements Development Risk Management Technical Solution Validation Verification Configuration Management Measurement and Analysis Project Monitoring and Control Project Planning Process and Product Quality Assurance Requirements Management Supplier Agreement Management Quality Productivity Risk Rework

21 Maturity Levels GG 2 and GG 3 All ML2, ML3, ML4, and ML5 PAs GG 2 and GG 3 All ML2, ML3, and ML4 PAs GG 2 and GG 3 All ML2 and ML3 PAs ML 5 ML 4 ML 3 Optimizing Daten aus der Prozessausführung werden beigezogen um die Erreichung von Geschäftszielen zu überprüfen, systematische Ursachenanalyse, kontrolliertes Continuous Improvement Quantitatively Managed es gibt qualitäts- und projektbezogene quantitative Ziele, diese werden mit Hilfe von statistischen und anderen quantitativen Techniken für die Führung beigezogen Defined Arbeitsabläufe sind umfassend beschrieben, es gibt ein projektspezifisches Tailoring von Standardprozessen, angepasste Prozessausführung GG 2 All ML2 PAs ML 2 Managed es gibt eine Unternehmenspolicy für die wichtigsten Prozesse, sie sind beschrieben, werden kontrolliert ausgeführt und reviewed ML 1 Initial Prozesse werden ad hoc und chaotisch ausgeführt

22 Appraisals Zertifizierung / Anerkennung durch SEI Appraisal nach SCAMPI (Standard CMMI Appraisal Method for Process Improvement) Evidenzbasiert (direkte / indirekte Nachweise für die Praktiken) 3 Klassen A: offiziell von SEI anerkannt B: Testlauf, Stand der Umsetzung C: Kurzanalyse zur Bestimmung Gaps Akkreditierte Lead Appraisers (low/high levels) Verbreitung (publizierte SCAMPI A gemäss SEI) L5: ca. 240 L4: ca. 90 L3: ca L2: ca

23 Agenda CMMI Referenzmodelle Aufbau am Beispiele CMMI-DEV Reifegrade und Appraisals in CMMI Praxisbeispiel im agilen Kontext

24 Das QMS der mimacom TQMi Total Quality Managementsystem, optimiert für Informatikunternehmen, nach ISO-9001:2011 Abdeckung sämtlicher Unternehmensbereiche History Einführung 2005, Rezertifizierungen 2008 / 2011 Jährliche interne und externe Audits Managementsysteme / Tools bis 2008: filebased (Word/Excel) ab 2009: Web / Wikibased Lösung (HTML plus Templates) für Managementsystem, Jira für die Bewirtschaftung tiefe Hürden, schnelle Zyklen, Akzeptanz (!)

25 Agile Development

26 HERMES und Agilität kombiniert User Centric Design, Rapid Protyping Klassisches Requirements Engineering Continuous Delivery, agile Softwareentwicklung

27 CMMI in der mimacom ag Motivation Nächster Schritt gemäss mimacom Vision (CI) Vertiefung im Bereich Softwaredevelopment Skalierung (international / national) Messbarkeit mit zunehmender Grösse Aktivitäten SCAMPI B mit Level 3 im Herbst 2008 abgeschlossen Dr. Prof. Somnuk Keretho, Uni Kasetsart, Thailand Implementierung CMMI L5 ab März 2011 Appraisal SCAMPI A L5 im August

28 CMMI und Agile?

29 Mögliche Ursachen Scrum ist nicht an allem schuld dasselbe gilt für CMMI

30 Eine mögliche Antwort Implementierung von CMMI in den bestehenden Prozessbeschreibungen nach TQMi («What» vs. «How») Scrum deckt OOTB L2, weitere Levels benötigen Erweiterungen ISO-9001 deckt L3 problemlos ab Erweiterung der bestehenden Templates und Checklisten Protokolle, Reviewberichte, Dashboards Insbesondere: Setup / Sprint 0 und Reviews im Projekt Qualitätsnormen für Übergänge nach Scrum (Qualitygates) Are you «ready-ready» to be «done-done»? Definition Of «Ready» / «Definition Of Done» Planningmeetings / Testingday Checklisten / Protokolle QPM / OPP: keine Angst vor agilen KPIs und Messungen Speed / Defects pro Sprint

31 mimacom path methods RD REQM PP QPM VAL VER RSKM PPQA QPM

32 Mapping Agile - CMMI SP 1.1 SP 1.2 SP 1.3 SP 1.4 CMMI-Practice Develop an understanding with the requirements providers on the meaning of the reqs. Obtain commitment to the requirements from the project participants. Manage changes to the requirements as they evolve during the project. Maintain bidirectional traceability among the requirements and work products Scrum-Practice Planning Meeting und Story Times des Teams mit dem Product Owner. Team-Commitment in Sprint- und Releaseplanning-Meetings. Story Times Führen von Changes im Product Backlog. Verwalten von Changes in den Planning- Meetings. Verwendung der mimacom toolchain oder ähnlichem (from Jira to Bamboo) Über Scrum nicht abgedeckt SP 1.5 Identify inconsistencies between the project plans and work products and the requirements. Daily Standup Meeting Release- und Sprintplanning-Meetings Backlog-Grooming Sprint-/Release-Burndown chart

33 Wrap up lessons learned CMMI ist in der Softwarentwicklung eine gute Möglichkeit, bestehende Prozesse zu vertiefen und zu verifizieren CMMI kann ein «Monster» sein, muss aber nicht it s up to you Als «What»-Modell lässt es genügend Freiraum für das «How» CMMI und agile Ansätze sind kombinierbar aber mit Kompromissen

34 Kundenorientiert Benutzerfreundlich Kompetent Qualitativ Effizient the open source integrator 34