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