Your SlideShare is downloading. ×
Agile Verträge
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Verträge

2,573
views

Published on

Die Präsentation der letzten AUG Saar Treffen.

Die Präsentation der letzten AUG Saar Treffen.

Published in: Business, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,573
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Manifest für Agile Softwareentwicklung

    Wir erschließen bessere Wege, Software zu entwickeln, indem wir dies selbst tun und anderen dabei helfen.
    Durch diese Tätigkeit haben wir schätzen gelernt:
    Individuen und Interaktionen mehr als Prozesse und Werkzeuge
    Funktionierende Software mehr als umfassende Dokumentation
    Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
    Reagieren auf Veränderung mehr als Befolgen eines Plans

    Das heißt, obwohl wir die Werte auf der rechten Seite schätzen, schätzen wir die Werte auf der linken Seite mehr.
    Prinzipien hinter dem Agilen Manifest
    Wir folgen diesen Prinzipien:
    Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
    Heisse sich ändernde Anforderungen selbst spät in der Entwicklung wilkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
    Liefere funktionierende Software regelmäßig im Wochen- oder Monatsrythmus, und bevorzuge dabei die kürzere Zeitspanne.

    Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
    Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

    Funktionierende Software ist das wichtigste Fortschrittsmaß.
    Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
    Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

    Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
    Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
    In regelmäßigen Abständen reflektiert das Team wie es effektiver werden kann und passt sein Verhalten entsprechend an.
  • Agile and adaptive approaches for linking people, projects and value
    We are a community of project leaders that are highly successful at delivering results. To achieve these results:
     
    We increase return on investment by making continuous flow of value our focus.
    We deliver reliable results by engaging customers in frequent interactions and shared ownership.
    We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
    We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
    We boost performance through group accountability for results and shared responsibility for team effectiveness.
    We improve effectiveness and reliability through situationally specific strategies, processes and practices.

    [©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.]
     
  • Ist möglich wenn die Anforderungen sehr stabil sind.

    öfters verwendet wenn beide Parteien sich gegenüber nicht vertrauen.
    in der Regel, verdreht sich die Situation während des Projektes zu Gunste einer der Partei und im Nachteil der andere.


    Meine Ansicht: ist machbar wenn der Zeitraum gering ist: 3 Monate.
  • The sad fact of the matter is that most organization’s processes are so incredibly inefficient that it is not too hard to get a free 30% in team efficiency by judiciously short-circuiting the official process. We save time and resources, thus bringing an over-budget, over-time project in on (near) budget, (near) time.

    The second part to the secret is that project leaders have been doing this for decades. I don’t know that it has documented very much, but old timers regularly tell me how they used what we would now call agile techniques to get impossible work done on time.
  • When the customer and contracted company can agree on a unit of delivery, such as function points or story points, then they can settle on a price for each unit delivered. A number of contract houses these days estimate the size of a project in function points, create a price per function point delivered, and then have an certified function point auditor assess the actual number of function points delivered in the end. The customer then pays that amount, not the originally estimated amount. This is a nice contract form, because it encourages the contracted company to work more efficiently (to increase their pay per delivered function point) and it allows the customer to change the requirements along the way.

    The same can be done with XP-style story points, except that there aren’t any certified story point examiners to judge the final result.
  • Typical Nokia Test Scores

    CSM classes start out at average score of 4.0
    By end of class, individuals think they can raise their teams to 6.0 by the end of one month
    Conservatively this will raise velocity by 20%.
    One month for one team costs about 100000 Euro. Cost reduction of 20%. Earlier time to market should generate revenue multiplier.
    Minimum return first year is 220000 and cost of Scrum Certification is less than 2000 Euro.
    ROI > 11000% first year
  • Use a standard fixed price contract which includes time and materials for changes
    Insert the Change for Free option clause.
    – The customer must execute this option by working with the Scrum Team every Sprint.
    – Failure to do this voids this clause and the contract reverts to time and materials.
    The Scrum Product Owner reprioritizes the Product Backlog at the end of each Sprint.
    Changes are included with these rules
    Changes in priorities are free if total contract work is not changed
    Requirements of customer
    Features are prioritized by business value and implemented in order of maximum value
    Users follows project closely and work with the Product Owner to produce a quality Product Backlog
    New features may be added for free at Sprint boundaries if low priority items of equal work are removed from contract.

  • Make the world a better place by altering the
    fundamental structure of the IT industry

    Implement the design goal of Scrum, bring all projects in early, disrupt waterfall competitors, and execute the early retirement plan!
  • Transcript

    • 1. Agile Verträge Treffen der Agile User Group Saar 23 Nov. 2010 Pierre Neis, Scrum Coach 1
    • 2. Agilität? Pierre Neis, Scrum Coach 2
    • 3. Manifest für Agile Softwareentwicklung Pierre Neis, Scrum Coach Individuen und Interaktionen • Funktionierende Software • Zusammenarbeit mit dem Kunden • Reagieren auf Veränderung Prozesse und Werkzeuge • umfassende Dokumentation • Vertragsverhandlung • Befolgen eines Plans 3
    • 4. Declaration of Interdependence Engaging Customers Improve Effectiveness R.O.I. Boost Performance Pierre Neis, Scrum Coach 4
    • 5. FEST PREIS, FEST RAHMEN (UND MÖGLICHERWEISE MIT FESTER ZEIT) ❶ Source: alistair.cockburn.us/Agile+contractsPierre Neis, Scrum Coach 5
    • 6. Das Dreieck Rahmen Zeit Ressourcen 3 Dimensionen Pierre Neis, Scrum Coach 6
    • 7. Das Dreieck Rahmen Zeit Ressourcen Wenn die 3 Dimensionen fix sind ist das Projekt über eingeschrenkt. Pierre Neis, Scrum Coach 7
    • 8. Das Hindernis umgehen.... Rahmen Zeit Ressourcen 3 Dimensionen + 1 Prozess Pierre Neis, Scrum Coach 8
    • 9. FEST PREIS PER FUNCTION POINT ODER STORY POINT ❷ Source: alistair.cockburn.us/Agile+contractsPierre Neis, Scrum Coach 9
    • 10. NOCH MEHR... VARIANTEN ❸ Source: alistair.cockburn.us/Agile+contractsPierre Neis, Scrum Coach 10
    • 11. Source: alistair.cockburn.us/Agile+contracts Zeit-und Materialaufwand NTE-FF: Not-to-exceed with fixed-fee Venture-capital financing model Norwegian PS 2000 Standard contract Missing in Action: Partial Delivery with Mandatory Requirements Changes Target-Cost contract Pierre Neis, Scrum Coach 11
    • 12. Pierre Neis, Scrum Coach 12
    • 13. MONEY FOR NOTHING, CHANGE FOR FREE ❶ Wir stimmen zur zusammen arbeit zu, und dadurch erschaffen wir Vertrauen und jede andere Kompetenz. Jeff SUTHERLANDPierre Neis, Scrum Coach 13
    • 14. Klauseln • Customer Participation in Scrum Team • Vorzeitiger Abschluss: “Money for Nothing” • Kostenloser Wächsel: “Change for free” • 100% er Scrum Pierre Neis, Scrum Coach 14
    • 15. 100% er Scrum Pierre Neis, Scrum Coach 15
    • 16. ① Iterationen Keine Iterationen 0 Iterationen > 6 Wochen 1 Variable Länge < 6 Wochen 2 Fixe Iteration, Länge 6 Wochen 3 Fixe Iteration, Länge 5 Wochen 4 Fixe Iteration, Länge 4 Wochen oder weniger 10 Pierre Neis, Scrum Coach 16
    • 17. ② Testing im Sprint Kein spezieller QA 0 Unit tested 1 Feature tested 5 Features tested sobald abgeschlossen 7 Software laüft Abnahmeprüfung 8 Software ist “deployed” 10 Pierre Neis, Scrum Coach 17
    • 18. ③ Agile Specification Keine Anforderungen 0 Grosse Anforderungen Dokumente 1 Arme user stories 4 Gute Anforderungen 5 Gute user stories 7 Just enough, just in time specifications 8 Gute User Stories gebunden mit erforderliche Spezifikationen 10 Pierre Neis, Scrum Coach 18
    • 19. ④ Product Owner Keinen Product Owner 0 Product Owner der Scrum nicht versteht. 1 Product Owner der das Team stört. 2 Product Owner not involved with team 2 Product owner mit klaren product backlog vom Team beschätzt vor dem Sprint Planning meeting (READY) 5 Product owner mit Release Roadmap mit Termine die auf der Team Velocity abgestimmt sind. 8 Product owner der das Team motiviert. 10 Pierre Neis, Scrum Coach 19
    • 20. ⑤ Product Backlog Keinen Product Backlog 0 Mehrere Product Backlogs 1 Einzigen Product Backlog 3 Product Backlog klar definiert und priorisiert auf ROI vor Sprint Planning (READY) 5 Product owner mit klaren product backlog geschätzt vom Team vor Sprint Planning meeting (READY) 5 Product Owner hat Release Burndown mit Release Termine auf Velocity basiert. 7 Product Owner kann ROI messen auf echtes Gewinn, Kosten per story point, oder andere Metriken. 10 Pierre Neis, Scrum Coach 20
    • 21. ⑥ Schätzungen Product Backlog ist nicht geschätzt 0 Schätzungen nicht von Team produziert 1 Schätzungen nicht durch Planung Poker produziert 5 Schätzungen durch Planning Poker von Team produziert. 8 Schätzung Fehler < 10% 10 Pierre Neis, Scrum Coach 21
    • 22. ⑦ Sprint Burndown Chart Kein Burndown Chart 0 Burndown Chart nicht von Team aktualisiert 1 Burndown Chart in Stunden/Tage ohne Berücksichtigung von work in progress (teil Tasks burn down) 2 Burndown chart nur wenn die Task erledigt ist (TrackDone pattern) 4 Burndown nur wenn die Story done ist. 5 Schreibe 3 Punkte, wenn Team die Velocity kennt. Schreibe 2 Punkte wenn der Product Owner den Release Plan auf der bekannte Velocity kalkuliert. Pierre Neis, Scrum Coach 22
    • 23. ⑧ Team Störung Manager oder Project Leader stört das Team 0 Product Owner stört das Team 1 Managers, Project Leaders oder Team leaders sagen den Leute was zu tun ist. 3 Habe Project Leader und Scrum Rollen 5 Niemand stört das Team, nur Scrum Rollen. 10 Pierre Neis, Scrum Coach 23
    • 24. ⑨ Team Aufgaben werden den Leute während des Sprint Plannings zu geteilt. 0 Team Leute haben keine Überschreitungen deren Fachgebiet. 0 Kein emergent Leadership – einen oder mehrere Team Mietglieder sind als direkte Instanz designiert. 1 Team hat nicht die erforderliche Kompetenz. 2 Team begeht gemeinsam Sprint Ziel und Backlog 7 Teammitglieder kämpfen gemeinsam gegen Hindernisse während des Sprints 9 Team ist in hyperproductiven Zustand 10 Pierre Neis, Scrum Coach 24
    • 25. CHANGE FOR FREE ❷ Pierre Neis, Scrum Coach 25
    • 26. Change for Free BusinessValue Zeit × Brauche dieses Tools Dieser brauche ich nicht mehr Pierre Neis, Scrum Coach 26
    • 27. Money for Nothing BusinessValue Zeit × Brauche dieses Tools Abrechen!ROI Abschnitt Kunde erhält 80% Lieferant erhält 20% Benutzer vermeiden Code aufblähen und unnötiger Funktionalitäten Projekte werden immer früher geliefert Pierre Neis, Scrum Coach 27
    • 28. MONEY FOR NOTHING & CHANGE FOR FREE ❸ Pierre Neis, Scrum Coach 28
    • 29. M4N & C4F •Vertragsbestimmungen •Development plan Pierre Neis, Scrum Coach 29
    • 30. Vertragsbestimmungen • Customer Engagement ermöglicht es uns, das System an die letzte bekannte Business Value zu skalieren. • Jede Anforderung, die nicht bereits auf gearbeitet wurde, kann mit einer anderen von gleichem Wert getauscht werden • Anforderungen Priorität kann vom Kunde geändert werden. • Der Kunde kann zusätzliche Versionen jederzeit anfragen, zu den dann geltenden Zeit-und Materialaufwand Fees. • Der Kunde kann den Vertrag kündigen wenn ein Restwert von minimal 20% vorsteht. Fixed Price, Fixed Date Pierre Neis, Scrum Coach 30
    • 31. Development plan • Product Owner Beteiligung erlaubt es uns, das System an die letzte bekannte Business Value zu skalieren. • Jede Anforderung, die nicht bereits auf gearbeitet wurde kann für einen anderen von gleichem Wert getauscht werden • Priorität der Anforderungen können durch Product Owner geändert werden • Product Owner kann zusätzliche Versionen jederzeit zu den dann geltenden Zeit-und Materialaufwand Zeitpläne anfragen. • Product Owner beendet Entwicklung und Releases des Produkt so bald er den Wert der nächsten Funktion erreicht hat Fixed Resources, Fixed Date Pierre Neis, Scrum Coach 31
    • 32. EMPFEHLUNGEN Pierre Neis, Scrum Coach 32
    • 33. Scrumbuts smells. Pierre Neis, Scrum Coach 33
    • 34. Gut für hyper produktiven Teams Pierre Neis, Scrum Coach 34
    • 35. Pierre Neis, Scrum Coach 35
    • 36. Danke • Scrum Coach & PMO – http://managingagile.blogspot.com/ • Domains: Finance, Government, VC’s, ICT, Industry, HR, AIFM • French-German Pierre Neis, Scrum Coach 36