vertraege in agilen projekten

Download Vertraege in Agilen Projekten

Post on 14-Jan-2015

5.114 views

Category:

Technology

0 download

Embed Size (px)

DESCRIPTION

Agile Werte basieren auf Vertrauen & Kooperation. Welche Vorgehens- und damit Vertragsmodelle sind dabei mglich? In diesen Slides versuche ich der Frage nachzuspren und stelle dabei verschiedene Modelle, ua. auch Money for Nothing, Changes for Free, vor. Der Vortrag wurde initial in einem Webinar gehalten, auf http://bit.ly/agilervertrag finden Sie das Video sowie weitere Information. Die Slides werde ich im Rahmen der kontinuierlichen Bearbeitung des Themas regelmig hier aktualisieren.

TRANSCRIPT

  • 1. Vertrge in Agilen Softwareprojekten Vertrauen & Kooperation Bjrn Schotte // @BjoernSchotte // bjoern.schotte@mayflower.de MAYFLOWER GmbH Disclaimer: keine Rechtsberatung! http://creativecommons.org/licenses/by-sa/3.0/deed.de

2. ber den Referenten: Bjrn Schotte Unruhestifter ;-) Geschftsfhrer MAYFLOWER GmbH Senior Consultant hilft Kunden, die Herausforderungen ihres Geschfts im Online Umfeld zu lsen. Bert konzeptionell & im Umfeld Agiler Methoden (Scrum, Enterprise Lean Startup) MAYFLOWER: 60+ Devs, Individualsoftware Web, Mobile & E- Business/E-Commerce 3. Ausgangslage Software-Entwicklung Cynefin (/knvn/) Modell Softwareentwicklung: Complex & Chaotic 4. Antwort auf Komplex & Chaotisch Agiles Projektvorgehen, emergente Praktiken Ich weiss heute nicht genau, was morgen sein wird Ich setze enge Korridore (Sprints), um kontinuierlich kleine Plne auf Sicht zu schmieden 5. Antwort auf Komplex & Chaotisch Upfront Design nur so viel wie notwendig und mglich ... denn ich will gerade Flexibilitt im Vorgehen haben Lasten-/Pflichtenheft: Irrglaube, die Dinge im Griff zu haben, teure CRs, sehr viel hhere TCO 6. Ausgangslage Vertragswesen Vertrge versuchen, Bekanntes zu regeln Vertrge versuchen, Sicherheit zu bieten Vertrge versuchen, Risiken zu verteilen Vertrge versuchen, Lsungen fr Probleme zu liefern Vertrge werden (gemeinhin) dann genutzt, wenn sich die Parteien nicht mehr vertragen 7. Ausgangslage Vertragswesen Kunden haben oftmals schlechte Erfahrungen mit Dienstleistern gemacht und versuchen sich durch Vertrge abzusichern (Risiko komplett auf Dienstleister abwlzen) dt. Werkvertragsrecht aus einer Zeit, als es noch keine Softwareentwicklung gab ... was heisst denn eigentlich Werkvertrag? 8. Ausgangslage Vertragswesen Definition Werkvertrag, Wikipedia: der Werkunternehmer schuldet dem Werkbesteller die Herstellung eines Werkes, das heit die Herbeifhrung eines bestimmten Erfolges tatschlicher Natur. Die Flligkeit der Vergtung des Werkvertrages tritt mit der Abnahme des Werkes ein. 9. hm ... 10. Softwareentwicklung ... 11. KOMPLEX ... 12. Ich habe ein Problem, fr das ich die Lsung noch nicht genau kenne 13. != Werkvertrag 14. Hey, lass uns doch einfach T&M machen! 15. Pures T&M = Risiko 100% auf Auftraggeberseite 16. Conclusio? 17. 1. Vertrge eignen sich scheinbar nicht fr agile Vorgehensweisen 18. 2. Software-Entwicklung = fr (un)bekannte Probleme mit noch unbekannten Lsungen (Scrum) Komplex! 19. 3. Software-Entwicklung = fr unbekannte Probleme mit noch unbekannten Lsungen (Lean Startup) Chaotisch! 20. Drama, Baby? 21. Annherung, Teil 1 22. GPL, GNU General Public License 23. Kooperation durch Tit-for-Tat 24. Nutze den Source, verndere ihn. Das ist okay. 25. Verteilst du die neue Software, liefere den gesamten Quellcode mit. Inklusive deiner nderungen. 26. Verhinderung von Missbrauch durch Hack des Vertrages (Lizenz). Erzwingt Kooperation. 27. bertragbar auf unsere Problematik? 28. Annherung, Teil 2 29. missbrauche Vertragsrecht zum Kooperationszwang 30. Zweck des Vertrages wandelt sich 31. weg von Definition von Bekanntem (wir wissen es eh nicht 100%ig) hin zur Definition Rahmen, der Kooperation regelt und Verletzung von Kooperation ahndet 32. Auch im Vertrag Konzentration auf die Strken agilen Vorgehens 33. Emergente Erkenntnisse nutzen, um flexibel am Markt zu agieren 34. Konzentration auf Generierung von hohem Business Value 35. Rahmen gestalten, der Kooperation ermglicht und Pflichten/Rechte definiert 36. Mangelnde Kooperation ahnden 37. Nein, nicht mit Pnalen. Es gibt viel schlauere Lsungen. 38. Conclusio? 39. 1. Vertragsgestaltung hacken 40. 2. Konzentration auf Kooperation und Generierung von Nutzen 41. 3. Realitt anerkennen. Empirie & emergentes Wissen zu Lsungen entsteht whrend des Projekts 42. Ergebnis: Auflsung Unvereinbarkeit Agiles Vorgehen - Vertragsrecht 43. Beispiele fr Vorgehens-/ Vertragsmodelle 44. Disclaimer - fr alles gilt: fragen Sie Ihren Anwalt fragen Sie Mayflower :-) have fun & viele erfolgreiche Projekte! 45. T&M - the good old one bei klassisch T&M Bezahlung jeder Stunde (zB Sprint-weise) Risiko 100% auf Auftraggeber-Seite ohne weitere Elemente (zB enges Scrum, hohe Motivation etc) wenig Anreiz fr den Dienstleister, hohen BV zu liefern dennoch: je nach Situation, Klarheit von Anforderungen, Mglichkeiten des Kunden kann pures T&M Sinn ergeben 46. T&M mit Abbruch bei klassisch T&M Bezahlung jeder Stunde (zB Sprint-weise) Kunde merkt nach N Sprints, dass nicht mehr viel Business Value zu holen ist mit einem Vorlauf von zB 1 Sprint kann der Kunde jederzeit nach einem Sprint das Projekt beenden Vorlauf notwendig, damit der Dienstleister die Ressourcen umplanen kann 47. T&M mit Abbruch: Beispiel Projekt ursprnglich auf 10 Sprints geplant gegen Ende Sprint 6 stellt der Kunde fest, dass kaum mehr BV zu holen ist, da sich die Marktbedingungen gendert haben Ende Sprint 6: Ankndigung, dass das Projekt mit dem Ende von Sprint 7 beendet wird Vorteile fr beide Seiten, Kooperation wird gesttzt: kein BV mehr realisierbar? Abbruchmglichkeit DL hat gengend Vorlauf zur Umplanung 48. T&M on steroids 49. Warnung: nur fr echte Mnner 50. Regel 1: T&M, sprint-weise Abrechnung aller Stunden 51. Steroids! Regel 2: Kunde kann ohne Angabe von Grnden einen Sprint nicht bezahlen 52. Steroids! Regel 3: Sonderkndigungsrecht DL, wenn der Kunde das 2. Mal einen Sprint nicht bezahlt 53. Ergebnis: Verkettung beider Seiten in Kooperation 54. der Kunde berlegt sich sehr genau, wann er einen Sprint nicht bezahlt 55. der Dienstleister hat ein Interesse an guter, ergebnisorientierter Arbeit 56. Achtung: macht nur Sinn fr Projekte, bei denen DL-Wechsel sehr schmerzhaft (teuer) ist und somit eine Garantie zur Kooperation bentigt wird Steroids! 57. MAYFLOWER nutzt T&M on steroids erfolgreich in Projekten. 58. Na, schon Herzrasen bekommen? 59. Ok, schalten wir einen Gang zurck. 60. Vertrag, klassisch, mit Gewerk und Jedns... 61. Klassischer Vertrag, Agil mit Festpreis Regel 1: im Vertrag ist Scrum-Vorgehen definiert Regel 2: beiden Parteien bewusst, dass kein fixes Feature-Set geliefert werden kann. Das Budget ist fix definiert. Regel 3: es kann kein Gesamtwerk definiert werden Ein Gewerk brauche ich fr Gewhrleistung. Ich brauche Sicherheit. Hilfe, was kann ich tun? 62. Klassischer Vertrag, Agil mit Festpreis Regel 4 (!): eine einzelne User Story stellt ein Mini-Gewerk da, auf das Gewhrleistungsregeln angewandt werden Regel 5 (!): das Team kann User Stories ablehnen, wenn diese aus ihrer Sicht nicht ausreichend spezifiziert/schtzbar sind (knnen wir das Werkvertragsrisiko hier bernehmen?) Regel 5 (! Variation): nach beidseitiger Rcksprache kann eine einzelne User Story dienstvertraglich behandelt werden Puh... ich hab Gewerk drin. Check. Doch wie ist das mit der Abnahme? 63. Klassischer Vertrag, Agil mit Festpreis Regel 6 (!): Abnahme des Mini-Gewerks im Sprint Review. Bei Nicht-Abnahme (weil Story nicht errreicht!) kommt die Story zurck ins Backlog und wird zB fr den nchsten Sprint wieder eingeplant. Regel 7 (!): monatlicher Zahlungsplan aufgrund der erbrachten Leistungen Regel 8 (!): wird eine bereits realisierte User Story durch eine neue US erweitert/ersetzt, so beginnt die Gewhrleistung neu Ok. Entkopplung Bezahlung von Gewhrleistung/Abnahme. Nur wenn im Nachhinein, also im Betrieb, etwas Abgenommenes nachweislich nicht stimmt, muss kostenlos gefixt werden. Das ist fair. 64. Kooperation auf beiden Seiten. 65. Vorgehen im Vertrag festgelegt. 66. Mini-Gewerke statt groes Gewerk. 67. Stakes von Legal & Procurement erfllbar. 68. MAYFLOWER nutzt Klassisch- agiler Festpreis erfolgreich in Projekten. 69. Back to Innovation: Money for Nothing, Changes for Free 70. Exkurs zurck ... 71. Vertrge, old school: Ich kenne die Features, ich kenne den ROI, ich kann alles definieren und regeln. 72. Das stimmt so nicht 73. Daher Agile Logik: 74. Ich investiere (und bezahle) Arbeitszeit 75. Ich erzeuge maximalen Business Value 76. und mache so lange weiter 77. bis es sich nicht mehr lohnt (Kosten Feature >> BV) 78. = bis es sich nicht mehr lohnt, weiter zu machen 79. Ausprgung dieses Prinzips ist Money for nothing, Changes for free 80. Regel 1: Standard fixed price Contract mit T&M fr Changes 81. Regel 2: Tausch von Features gleicher SP Zahl mglich, sofern an US noch nicht begonnen (Changes for Free) 82. Regel 2a: Neue Features mglich, wenn Low Prio Features gleicher SP-Zahl wegfallen 83. Anforderung an Kunde & DL: es gibt ein qualitativ gutes Backlog, Gesamt-Features sind gut schtzbar! Achtung! 84. Regel 3: hlt der Kunde sich nicht an Scrum, wandelt sich das Projekt in reines T&M 85. Nun zum Money for Nothing ... 86. Regel 4: ebenfalls nur gltig, wenn Scrum Vorgehen eingehalten 87. Regel 5: beide Parteien knnen sich auf SP Estimates einigen. Ansonsten Umwandlung in T&M 88. Regel 6: wenn Kosten Feature >> BV dann Projekt-Abbruch 89. Regel 7: Ausgleich fr frhzeitige Beendigung des Projekts: 20% des brig gebliebenen Budgets geht zustzlich an DL (Money for Nothing) 90. Hmm. Wann ist der Einsatz von M4NC4F sinnvoll? 91. Nur bei BV Optimierung! Nur wenn klar ist, dass ich das Budget nicht bis zum Ende aufbrauchen will. Achtung! 92. M4NC4F lohnt sich nicht, wenn das Budget sowieso gut und sinnvoll genutzt werden kann.(iSv gute Business Value Generierung regelmig mglich) Achtung! 93. MAYFLOWER nutzt M4NC4F erfolgreich in Projekten. 94. Finale ... ein paar Empfehlungen 95. Konzentrieren Sie sich auf vertrauensvolles Arbeiten auf Augenhhe 96. Setzen Sie im Vertrag nur einen Rahmen, der Kooperation gar