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

®

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


Agile Entwicklung



Geschäftspolitische Einflüsse

Minimal Signifikant

21


Agile Entwicklung



Organisatorisches Umfeld(Outsourcing, Partner)

In-house Third party


Minimal Signifikant

22


Agile Entwicklung




Grad der Governance


Informal Formal


Minimal Signifikant

23


Agile Entwicklung




Teamgröße

unter 10 über 100

Grad der Governance


Informal Formal


Minimal Signifikant

24


Agile Entwicklung



Anwendungskomplexität

EinfachHomogen

Komplex, Heterogen


Teamgröße

unter 10 über 100

Grad der Governance


Informal Formal


Minimal Signifikant

25


Agile Entwicklung

Lokal

Geografische Verteilung

Global



Anwendungskomplexität

EinfachHomogen

Komplex, Heterogen


Teamgröße

unter 10 über 100

Grad der Governance


Informal Formal


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


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


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.

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

Documents

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