26-mal heruntergeladen
Hochgeladen vonPierre E. NEIS
Agile Verträge
Das Dokument behandelt agile Verträge und deren Anwendung in der Softwareentwicklung, insbesondere im Kontext von Scrum. Pierre Neis erläutert das Manifest für agile Softwareentwicklung, Vertragsmodelle und die Bedeutung der Kundenbeteiligung sowie iterative Prozesse. Wichtige Punkte sind das Management von Ressourcen, Zeitplänen und die Flexibilität innerhalb der projektbezogenen Verträge.
Weitere ähnliche Inhalte
Agile Verträge
- 1. Agile Verträge Treffen derAgile User Group Saar 23 Nov. 2010 Pierre Neis, Scrum Coach 1
- 2. Agilität? Pierre Neis, ScrumCoach 2
- 3. Manifest für AgileSoftwareentwicklung 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.
- 5. FEST PREIS, FESTRAHMEN (UND MÖGLICHERWEISE MIT FESTER ZEIT) ❶ Source: alistair.cockburn.us/Agile+contractsPierre Neis, Scrum Coach 5
- 6. Das Dreieck Rahmen Zeit Ressourcen 3Dimensionen Pierre Neis, Scrum Coach 6
- 7. Das Dreieck Rahmen Zeit Ressourcen Wenndie 3 Dimensionen fix sind ist das Projekt über eingeschrenkt. Pierre Neis, Scrum Coach 7
- 8. Das Hindernis umgehen.... Rahmen Zeit Ressourcen 3Dimensionen + 1 Prozess Pierre Neis, Scrum Coach 8
- 9. FEST PREIS PERFUNCTION 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-exceedwith 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, ScrumCoach 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 Participationin 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 PierreNeis, Scrum Coach 15
- 16. ① Iterationen Keine Iterationen0 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 imSprint 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 KeineAnforderungen 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 KeinenProduct 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 KeinenProduct 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 Backlogist 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 BurndownChart 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 Manageroder 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 werdenden 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 ❷ PierreNeis, Scrum Coach 25
- 26. Change for Free BusinessValue Zeit × Brauchedieses Tools Dieser brauche ich nicht mehr Pierre Neis, Scrum Coach 26
- 27. Money for Nothing BusinessValue Zeit × Brauchedieses 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 •Developmentplan Pierre Neis, Scrum Coach 29
- 30. Vertragsbestimmungen • Customer Engagementermö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 • ProductOwner 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, ScrumCoach 32
- 33.
- 34. Gut für hyperproduktiven Teams Pierre Neis, Scrum Coach 34
- 35. Pierre Neis, ScrumCoach 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
Hinweis der Redaktion
- #4 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.
- #5 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.]
- #6 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.
- #9 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.
- #10 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.
- #25 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
- #27 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.
- #36 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!