® IBM Software Group Mit ganzheitlichen Verfahren Grenzen durchbrechen © 2010 IBM Corporation
Willkommen! Arno Dämon IBM Deutschland Wilhelm-Fay-Straße 30 -34 D-65936 Frankfurt-Sossenheim Phone: +49 -170 63 10 406 E-Mail: arno. daemon@de. ibm. com 2
Agil an jedes Ziel? „Die ganzheitliche Betrachtung der agilen Prozesse reduziert die Aufwände an den Nahtstellen und erhöht die Effizienz und Transparenz. “ 3
Definition der agilen Werte Individuals Interactions Processes and Tools Working Software Comprehensive Documentation We value over Customer Collaboration Contract Negotiation Respond to Change Following a Plan That is, while there is value in the items on the right, we value the items on the left more. (Source: www. agilemanifesto. org) 4 4
100% Agil? §Um von agilen Methoden zu profitieren müssen nicht alle Praktiken im Projekt in gleich hohem Maß implementiert sein. §Pragmatismus sollte vor formalen Kriterien wie dem „Nokia-Test“ kommen. 5 Pure Agile Formal Level of Agility
Agile ist Mainstream… 6
Die Nahtstellen 7
Die Nahtstellen Perfekt für die Implementierung 8
Die Nahtstellen Bei vielen Projekten besteht jedoch Anpassungsbedarf 9
Anpassungsbedarf § Was, wenn… 4 der Kunde eine vertraglich festgelegte funktionale Leistungsbeschreibung und eine Lieferfrist wünscht? 4 ein Software-Produkt unternehmensweit ausgerollt und eingesetzt werden soll? 4 der Kunde einen langatmigen Zulassungsprozess für das „fertige“ Produkt hat? 4 es kritische Sicherheitsanforderungen gibt? 4 der Kunde von Ihnen geographisch entfernt ist? 4 der Kunde zu beschäftigt ist, um mit Ihnen häufigen Kontakt zu haben? 10
Die Nahtstellen 11
Requirements, Anforderungen, Backlogs Kontradiktional? § Requirements Engineering ist die Methode um 4 Anforderungen aufzunehmen 4 Anforderungen präzise und in sich schlüssig zuformulieren 4 Kurz und prägnant zu dokumentieren 4 Inhaltliche Konsistenz herbeizuführen § Aufgaben des Product Owners 4 Erfassung der Kundenbedürfnisse 4 Beschreibung der Anforderungen 4 Kommunikation mit Stakeholdern 4 Projektmanagement 4 Kommunikation mit dem Team 12
Requirements, Anforderungen, Backlogs Kontradiktional? § Die Aufgaben des Product-Owners und des Requirements Engineers sind sehr vergleichbar § Eine formales Requirements Engineering kann problemlos der Implementierung mit agilen Methoden vorangestellt werden. 4 Der Product Owner wird entlastet 4 Die Qualität des Backlogs wird durch einen erfahrenen Requirments Engineer erhöht 4 Formale Vorgeben der Kunden werden eher erfüllt § Klassisches Requirements Engineering kann die Umsetzbarkeit von agilen Methoden wie Scrum erhöhen 13
Test Driven Development und Independent Testing §Die Effektivität des Teams verbessert sich wenn funktionierende Build regelmäßig einem investigativen Test unterzogen werden. z. B. §Pre-production system integration testing §Usability testing §Security testing §Non-functional testing 14
Erweiterter Ansatz Am Beispiel von Disciplined Agile Development 15
Erweiterter Ansatz 17
Erweiterter Ansatz 18
… aber Agilität muss oft auch skalieren können Management der Anforderungen Kritisch, auditfähig geringes Risiko Agile Entwicklung 19
… aber Agilität muss oft auch skalieren können Management der Anforderungen Kritisch, auditfähig geringes Risiko Geschäftspolitische Einflüsse Minimal Agile Entwicklung 20 Signifikant
… aber Agilität muss oft auch skalieren können Management der Anforderungen Kritisch, auditfähig geringes Risiko Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) In-house 21 Third party
… aber Agilität muss oft auch skalieren können Management der Anforderungen Kritisch, auditfähig geringes Risiko Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Third party In-house Grad der Governance Informal 22 Formal
… aber Agilität muss oft auch skalieren können Management der Anforderungen Kritisch, auditfähig geringes Risiko Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Third party In-house Teamgröße unter 10 Grad der Governance über 100 Informal 23 Formal
… aber Agilität muss oft auch skalieren können Management der Anforderungen Kritisch, auditfähig geringes Risiko Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Anwendungskomplexität Einfach Homogen Komplex, Heterogen Teamgröße unter 10 Third party In-house Grad der Governance über 100 Informal 24 Formal
… aber Agilität muss oft auch skalieren können Management der Anforderungen Kritisch, auditfähig geringes Risiko Geografische Verteilung Lokal Geschäftspolitische Einflüsse Global Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Anwendungskomplexität Einfach Homogen Komplex, Heterogen Teamgröße unter 10 Third party In-house Grad der Governance über 100 Informal 25 Formal
Inhärente Grenzen Agile Vorgehensmodelle gehen von Teams aus die aus maximal 10 Personen bestehen 14 510 11+ Average number of relationships: 3 26 55+ Estimated average management hours a: 15 48 68+ Productivity: OK Great Poor Team size: a Based on PMI estimate of 10% - 25% of total hours 26 4 people 6 relationships 5 people 12 people 10 relationships 66 relationships
Agile Team Organisation Generische Team Rollen: 4 Team Lead 4 Developers/Team Members 4 Product Owner 4 Stakeholders (nicht dargestellt) Unterstützende Rollen (Supporting cast): 4 Technical Experts 4 Mitarbeit bei Bedarf 4 Domain Experts 4 Requirements Breakdown und Project-Vision 4 Independent Tester 27
Grosse Teams können mit mehr Rollen effektiver sein. § Architecture Owner 4 Erleichtert technische Entscheidungen und koordiniert technische Diskussionen im Team § Domain Expert 4 Hat Wissen über eine oder mehrere Aspekte des Problemgebietes einzeln aufgeführt § Technical Expert 4 Hat technisches Detailwissen, wird punktuell hinzugezogen § Independent Tester 4 Bearbeite komplexe Tests und arbeitet parallel und unabhängig vom Team § Integrator 4 Ist für den Build des Gesamtsystems zuständig § Specialist 4 Zum Beispie: l. Business Analysten, Security Experten, Usability Professionals 28
Welche Aufteilung der Backlogs macht Sinn? Using a single Backlog for multiple Teams Story 1 Team 1 Story 2 Product Backlog Story 1 Story 2 Story 3 Story 4 Team 2 Story 4 Story 5 Story 6 Story 7 Story 5 Story 6 29 Team 3
Welche Aufteilung der Backlogs macht Sinn? Team 1 Story 1 Using a multiple Backlog for multiple Teams Story 2 Story. . n Product Backlog Story 1 Story 2 Story 1 Story 3 Team 2 Story 4 Story. . n Story 5 Story 6 Story 7 Story 1 Story 2 Story. . n 30 Team 3
Welche Aufteilung der Backlogs macht Sinn? Using a single Backlog for multiple Teams by features Product Backlog Team 1 Feature 1 Story F 1 -1 Team 2 Story F 2 -1 Story F 2 -2 Feature 2 Team 3 Story F 3 -1 Feature 3 Story F 3 -1 Story F 3 -2 Story F 3 -1 31
Wie soll das ganze effizient und agil koordiniert werden ? 32
Collection Requirement Use Cases Sketches Bus. Goals Requirements Discipline Release Plan (Backlog) Testplan Iteration Plan (Sprint) Test Milestone Story Test Case Task Test Script Build Test Execution Record Defect Testing Discipline Development Discipline 33
Collection Requirement Use Cases Sketches Bus. Goals Release Plan (Backlog) Iteration Plan (Sprint) Rational Requirements Composer Requirements Discipline Testplan Test Milestone Story Test Case Task Test Script Build Test Execution Record Defect Rational Team Concert Development Discipline Rational Quality Manager 34 Testing Discipline
Zusammenfassung Organizational Drivers Team Size Geographical Distribution Organization Distribution Entrenched process, people, policy c S e@ il Ag D DA ale §Mature or existing projects §Many developers §Complex, multi-platform applications §Distributed teams §Need for scalability, reproducibility, and traceability §Maturing projects §Multi-platform §Growing in complexity §Remote or offshore work §Greater need for coordination and handoffs m , XP ru Sc §Small team §New projects §Simple application §Co-located §Minimal need for documentation Technical and Regulatory Drivers Compliance Governance Application complexity 35
Fazit § Agile Methoden wie Scrum haben ihre Grenzen, aber diese lassen sich beherrschen. § Dennoch lohnt sich immer eine Analyse über mögliche Einsatzgebiete, denn die Erfahrung zeigt das: 4 Durch eine geschickte Auswahl der Praktiken 4 Zielgerichteter Einsatz unterstützender Lösungen 4 Frühzeitige Prozessanalysen und Methodenplanung § Sehr viele mehr Projekte von den agilen Methoden profitiere können. 36
IBM Agile Resources Besuchen Sie unseren Stand (6. 3) um sich vom Portfolio an Lösungen für die Entwicklung von Software und Systemen selbst zu überzeugen. www. ibm. com/rational/agile/ www. ibm. com/developerworks/blogs/page/ambler 37
© Copyright IBM Corporation 2011. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 38
Скачать презентацию IBM Software Group Mit ganzheitlichen Verfahren Grenzen
0433c18a42ba389a0c838e86b2ffda07.ppt