Upload
han-effertz
View
105
Download
2
Embed Size (px)
Citation preview
®
IBM Software Group
© 2010 IBM Corporation
Mit ganzheitlichen Verfahren Grenzen durchbrechen
2
Willkommen!
Arno Dämon
IBM Deutschland
Wilhelm-Fay-Straße 30-34
D-65936 Frankfurt-Sossenheim
Phone: +49-170 63 10 406
E-Mail: [email protected]
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
Working SoftwareWorking Software
Individuals InteractionsIndividuals Interactions
Respond to ChangeRespond
to Change
Customer Collaboration
Customer Collaboration
ComprehensiveDocumentationComprehensiveDocumentation
Processes and ToolsProcesses and Tools
Following a Plan
Following a Plan
ContractNegotiation
ContractNegotiation
overWe value
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
Definition der agilen Werte
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
Agile ist Mainstream…
7
Die Nahtstellen
8
Die Nahtstellen
Perfekt für die Implementierung
9
Die Nahtstellen
Bei vielen Projekten besteht jedoch
Anpassungsbedarf
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
Die Nahtstellen
12
Requirements, Anforderungen, Backlogs Kontradiktional?
Requirements Engineering ist die Methode umAnforderungen aufzunehmen Anforderungen präzise und in sich schlüssig zuformulierenKurz und prägnant zu dokumentierenInhaltliche Konsistenz herbeizuführen
Aufgaben des Product OwnersErfassung der KundenbedürfnisseBeschreibung der AnforderungenKommunikation mit StakeholdernProjektmanagementKommunikation mit dem Team
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 entlastetDie 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
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
Erweiterter Ansatz
Am Beispiel von Disciplined Agile Development
17
Erweiterter Ansatz
18
Erweiterter Ansatz
19
… aber Agilität muss oft auch skalieren können
Agile Entwicklung
Management der Anforderungen
geringes Risiko Kritisch,auditfähig
20
… aber Agilität muss oft auch skalieren können
Agile Entwicklung
Management der Anforderungen
geringes Risiko Kritisch,auditfähig
Geschäftspolitische Einflüsse
Minimal Signifikant
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
Minimal Signifikant
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
Minimal Signifikant
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
Minimal Signifikant
24
… aber Agilität muss oft auch skalieren können
Agile Entwicklung
Management der Anforderungen
geringes Risiko Kritisch,auditfähig
Anwendungskomplexität
EinfachHomogen
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
Minimal Signifikant
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
EinfachHomogen
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
Minimal Signifikant
26
Agile Vorgehensmodelle gehen von Teams aus die aus maximal 10 Personen bestehen
Inhärente Grenzen
4 people 5 people 12 people6 relationships 10 relationships 66 relationships
Team size:1 - 4
5 - 10
11+
Average number of relationships: 3 26 55+
Estimated average management hours a:
15 48 68+
Productivity: OK Great Poor
a Based on PMI estimate of 10% - 25% of total hours
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
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
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
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
Story ..n
Story ..n
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
Wie soll das ganze effizient und agil koordiniert werden ?
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 DisciplineTesting Discipline
34
Rational Team ConcertRational Team Concert
Release Plan(Backlog)
Iteration Plan(Sprint)
Story
Task
Rational Requirements Composer
Rational Requirements Composer
Collection
Requirement
Sketches
Bus. Goals
Rational Quality ManagerRational Quality Manager
Testplan
Test Milestone
Test Case
Use Cases
Build
Test Script
Test Execution Record
Defect
Requirements Discipline
Development Discipline Testing Discipline
35
Zusammenfassung
Technical and Regulatory Drivers ComplianceGovernance
Application complexity
Organizational DriversTeam Size
Geographical DistributionOrganization Distribution
Entrenched process, people, policy
Small teamNew projectsSimple applicationCo-locatedMinimal need for documentation
Maturing projectsMulti-platformGrowing in complexityRemote or offshore workGreater need for coordination and handoffs
Mature or existing projectsMany developersComplex, multi-platform applicationsDistributed teamsNeed for scalability, reproducibility, and traceability
Agile @Scale
XP, Scrum
DAD
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 PraktikenZielgerichteter Einsatz unterstützender LösungenFrühzeitige Prozessanalysen und Methodenplanung
Sehr viele mehr Projekte von den agilen Methoden profitiere können.
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.
www.ibm.com/rational/agile/
www.ibm.com/developerworks/
www.ibm.com/developerworks/blogs/page/ambler
38
© 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.