Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

® IBM Software Group © 2010 IBM Corporation Mit ganzheitlichen Verfahren Grenzen durchbrechen.

Ähnliche Präsentationen


Präsentation zum Thema: "® IBM Software Group © 2010 IBM Corporation Mit ganzheitlichen Verfahren Grenzen durchbrechen."—  Präsentation transkript:

1 ® IBM Software Group © 2010 IBM Corporation Mit ganzheitlichen Verfahren Grenzen durchbrechen

2 2 Willkommen! Arno Dämon IBM Deutschland Wilhelm-Fay-Straße D Frankfurt-Sossenheim Phone:

3 3 Agil an jedes Ziel? Die ganzheitliche Betrachtung der agilen Prozesse reduziert die Aufwände an den Nahtstellen und erhöht die Effizienz und Transparenz.

4 4 Working Software Working Software Individuals Interactions Respond to Change Customer Collaboration Customer Collaboration Comprehensive Documentation Comprehensive Documentation Processes and Tools Following a Plan Contract Negotiation Contract Negotiation overWe value That is, while there is value in the items on the right, we value the items on the left more. ( Source: 4 Definition der agilen Werte

5 5 100% Agil? Level of Agility Formal Pure Agile 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.

6 6 Agile ist Mainstream…

7 7 Die Nahtstellen

8 8 Perfekt für die Implementierung

9 9 Die Nahtstellen Bei vielen Projekten besteht jedoch Anpassungsbedarf

10 10 Anpassungsbedarf Was, wenn… der Kunde eine vertraglich festgelegte funktionale Leistungsbeschreibung und eine Lieferfrist wünscht? ein Software-Produkt unternehmensweit ausgerollt und eingesetzt werden soll? der Kunde einen langatmigen Zulassungsprozess für das fertige Produkt hat? es kritische Sicherheitsanforderungen gibt? der Kunde von Ihnen geographisch entfernt ist? der Kunde zu beschäftigt ist, um mit Ihnen häufigen Kontakt zu haben?

11 11 Die Nahtstellen

12 12 Requirements, Anforderungen, Backlogs Kontradiktional? Requirements Engineering ist die Methode um Anforderungen aufzunehmen Anforderungen präzise und in sich schlüssig zuformulieren Kurz und prägnant zu dokumentieren Inhaltliche Konsistenz herbeizuführen Aufgaben des Product Owners Erfassung der Kundenbedürfnisse Beschreibung der Anforderungen Kommunikation mit Stakeholdern Projektmanagement Kommunikation mit dem Team

13 13 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. Der Product Owner wird entlastet Die Qualität des Backlogs wird durch einen erfahrenen Requirments Engineer erhöht Formale Vorgeben der Kunden werden eher erfüllt Klassisches Requirements Engineering kann die Umsetzbarkeit von agilen Methoden wie Scrum erhöhen

14 14 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

15 15 Erweiterter Ansatz Am Beispiel von Disciplined Agile Development

16 16 Erweiterter Ansatz

17 17 Erweiterter Ansatz

18 18 Erweiterter Ansatz

19 19 … aber Agilität muss oft auch skalieren können Agile Entwicklung Management der Anforderungen geringes Risiko Kritisch, auditfähig

20 20 … aber Agilität muss oft auch skalieren können Agile Entwicklung Management der Anforderungen geringes Risiko Kritisch, auditfähig Geschäftspolitische Einflüsse MinimalSignifikant

21 21 … aber Agilität muss oft auch skalieren können Agile Entwicklung Management der Anforderungen geringes Risiko Kritisch, auditfähig Organisatorisches Umfeld (Outsourcing, Partner) In-house Third party Geschäftspolitische Einflüsse MinimalSignifikant

22 22 … aber Agilität muss oft auch skalieren können Agile Entwicklung Management der Anforderungen geringes Risiko Kritisch, auditfähig Organisatorisches Umfeld (Outsourcing, Partner) Grad der Governance In-house Third party Informal Formal Geschäftspolitische Einflüsse MinimalSignifikant

23 23 … aber Agilität muss oft auch skalieren können Agile Entwicklung Management der Anforderungen geringes Risiko Kritisch, auditfähig Organisatorisches Umfeld (Outsourcing, Partner) Teamgröße unter 10über 100 Grad der Governance In-house Third party Informal Formal Geschäftspolitische Einflüsse MinimalSignifikant

24 24 … aber Agilität muss oft auch skalieren können Agile Entwicklung Management der Anforderungen geringes Risiko Kritisch, auditfähig Anwendungskomplexität Einfach Homogen Komplex, Heterogen Organisatorisches Umfeld (Outsourcing, Partner) Teamgröße unter 10über 100 Grad der Governance In-house Third party Informal Formal Geschäftspolitische Einflüsse MinimalSignifikant

25 25 … aber Agilität muss oft auch skalieren können Agile Entwicklung Lokal Geografische Verteilung Global Management der Anforderungen geringes Risiko Kritisch, auditfähig Anwendungskomplexität Einfach Homogen Komplex, Heterogen Organisatorisches Umfeld (Outsourcing, Partner) Teamgröße unter 10über 100 Grad der Governance In-house Third party Informal Formal Geschäftspolitische Einflüsse MinimalSignifikant

26 26 Agile Vorgehensmodelle gehen von Teams aus die aus maximal 10 Personen bestehen Inhärente Grenzen 4 people 5 people 12 people 6 relationships 10 relationships 66 relationships Team size: Average number of relationships: Estimated average management hours a : Productivity: OKGreatPoor a Based on PMI estimate of 10% - 25% of total hours

27 27 Agile Team Organisation Generische Team Rollen: Team Lead Developers/Team Members Product Owner Stakeholders (nicht dargestellt) Unterstützende Rollen (Supporting cast): Technical Experts Mitarbeit bei Bedarf Domain Experts Requirements Breakdown und Project-Vision Independent Tester

28 28 Grosse Teams können mit mehr Rollen effektiver sein. Architecture Owner Erleichtert technische Entscheidungen und koordiniert technische Diskussionen im Team Domain Expert Hat Wissen über eine oder mehrere Aspekte des Problemgebietes einzeln aufgeführt Technical Expert Hat technisches Detailwissen, wird punktuell hinzugezogen Independent Tester Bearbeite komplexe Tests und arbeitet parallel und unabhängig vom Team Integrator Ist für den Build des Gesamtsystems zuständig Specialist Zum Beispie: lBusiness Analysten, Security Experten, Usability Professionals

29 29 Team 1 Team 2 Team 3 Product Backlog Welche Aufteilung der Backlogs macht Sinn? Story 1 Story 2 Story 3 Story 4 Story 5 Story 6 Story 7 Story 1 Story 2 Story 3 Story 4 Story 5 Story 6 Using a single Backlog for multiple Teams

30 30 Team 1 Team 2 Team 3 Product Backlog Welche Aufteilung der Backlogs macht Sinn? Story 1 Story 2 Story 3 Story 4 Story 5 Story 6 Story 7 Story 1 Story 2 Story 1 Story 2 Story 1 Story 2 Using a multiple Backlog for multiple Teams Story..n

31 31 Team 1 Team 2 Team 3 Product Backlog Welche Aufteilung der Backlogs macht Sinn? Story F1-1 Using a single Backlog for multiple Teams by features Feature 1 Feature 2 Feature 3 Story F2-1 Story F2-2 Story F3-1 Story F3-2 Story F3-1 Story F1-1 Story F2-1 Story F2-2 Story F3-1 Story F3-2 Story F3-1

32 32 Wie soll das ganze effizient und agil koordiniert werden ?

33 33 Release Plan (Backlog) Iteration Plan (Sprint) Story Task Collection Requirement Sketches Bus. Goals Testplan Test Milestone Test Case Use Cases Build Test Script Test Execution Record Defect Requirements Discipline Development Discipline Testing Discipline

34 34 Rational Team Concert Release Plan (Backlog) Iteration Plan (Sprint) Story Task Rational Requirements Composer Collection Requirement Sketches Bus. Goals Rational Quality Manager Testplan Test Milestone Test Case Use Cases Build Test Script Test Execution Record Defect Requirements Discipline Development Discipline Testing Discipline

35 35 Zusammenfassung Technical and Regulatory Drivers Compliance Governance Application complexity Organizational Drivers Team Size Geographical Distribution Organization Distribution Entrenched process, people, policy Small team New projects Simple application Co-located Minimal need for documentation Maturing projects Multi-platform Growing in complexity Remote or offshore work Greater need for coordination and handoffs Mature or existing projects Many developers Complex, multi-platform applications Distributed teams Need for scalability, reproducibility, and traceability XP, Scrum DAD

36 36 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: Durch eine geschickte Auswahl der Praktiken Zielgerichteter Einsatz unterstützender Lösungen Frühzeitige Prozessanalysen und Methodenplanung Sehr viele mehr Projekte von den agilen Methoden profitiere können.

37 37 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.

38 38 © Copyright IBM Corporation 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 IBMs 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.


Herunterladen ppt "® IBM Software Group © 2010 IBM Corporation Mit ganzheitlichen Verfahren Grenzen durchbrechen."

Ähnliche Präsentationen


Google-Anzeigen