Gewerke in agilen Projekten

Kommentare

5 Antworten zu „Gewerke in agilen Projekten“

1. 

   @mintao

   9. Januar 2013

   Gewerke in agilen Projekten http://t.co/WVlP7WKF via @mayflowerphp

   Antworten
2. 

   Mayflower (@mayflowerphp)

   9. Januar 2013

   Lesenswert: Gewerke in agilen Projekten http://t.co/kR1eXJ1O

   Antworten
3. 

   Björn Schotte

   9. Januar 2013

   Gerrit Beine frug auf Xing, welche alternativen Möglichkeiten es noch gibt: mir fällt zum Beispiel ein, dass man auch einen Sprint als Gewerk bezeichnen könnte, da ein Sprint ja eine fix definierte Menge an Stories enthält.

   Hierbei sollte IMHO darauf geachtet werden, dass nur die im Sprint Review vom PO abgenommenen User Stories als ein Gewerk gelten, um Fälle wie „Tausch gleichwertiger User Stories im Sprint“ abzudecken. Ich persönlich finde jedoch die User Story als Gewerk am attraktivsten, da es mir als kleinste atomare Einheit erscheint.

   Antworten
4. 

   Arno

   10. Januar 2013

   Also Werkvertrag lohnt sich m.E. gar nicht. Wenn der Kunde bei der Abnahme nachlässig ist, weil er schnell live gehen möchte und dann ständig Bugs meldet, ist das nur Aufwand. Ich habe auch schon Verträge von einem Fernsehsender gesehen, der dann die Bugs innerhalb von 6 Stunden behoben haben wollte, da hat man keinen Spaß.
   Typischerweise wollen die Kunden auch sofort die Entwicklung starten, statt ständig Spezifikation schreiben, da kommt dann oft „machen sie einfach mal“, schon aus Angst dass man Änderungen für falsche Vorgaben später zahlen muss. Viele Kunden liefern auch bewusst keine Details, um bei der Abnahme den Preis nochmal drücken zu können.
   Einige Agenturen verkaufen die Spezifikation der User Stories nach Tagessätzen, weil unerfahrene Kunden bei kleinsten Dingen ewig diskutieren. Manche Kunden versäumen auch gerne mal die Meetings oder die Server werden nicht rechtzeitig bestellt, dann hat man gleich 1-2 Wochen Stillstand. Wenn man eine vernünftige Spezifikation schreibt, kostet das meist so viel wie der Code selbst, das versteht aber kein Kunde.
   Werkverträge wurden ursprünglich für kleine Projekte wie Tische, Stühle und Schränke entwickelt, nicht für komplexe Software mit Millionen Zeilen Code. Wenn ich zu Audi gehe und denen sage, dass sie mir ein Auto bauen sollen und ich gebe denen dann jede Woche ein paar User Stories, die würden mich sofort rauswerfen. Ich habe auch noch keinen Anwalt gesehen, der mir für seine Dienste einen Werkvertrag anbietet. Mit einem Dienstvertrag für jeweils 3 Monate sind beide Seiten meist viel besser dran.

   Antworten
   1. 

      Björn Schotte

      10. Januar 2013

      Hallo Arno,
      vielen Dank für deinen interessanten Kommentar. Ich versuche hier mal auf die einzelnen Punkte einzugehen:

      Werk- vs. Dienstvertrag: ja, es kann gut der Fall sein, dass ein Projekt auf Dienstvertragsbasis mehr Sinn macht als auf werkvertraglicher Basis. Vielleicht nicht unbedingt aus den von dir genannten Gründen (Schuld/Risikoverschiebung beim/auf den Kunden). Wir sehen zum Beispiel in manchen Projektkonstellationen auf Dienstvertragsbasis vor, dass der Kunde nach einem Sprint das Recht hat, das Projekt schlicht zu beenden (hoffentlich, weil genügend Value da ist und nicht, weil er mit uns unzufrieden ist). Es kommt eben ganz auf die Projektart und -konstellation an. Zudem unterscheiden wir in der Regel auch zwischen werkvertraglichen und dienstvertraglichen Aufwendungen, womit sich ein „gemischter“ Vertrag ergeben kann: manche Dinge, wie zB Sprint Meetings, Konzept-Spikes, Support o.ä., lassen sich eben nicht werkvertraglicher Natur erledigen.

      Spezifikation der User Stories: wir haben gute Erfahrung damit gemacht, in einem „Sprint 0“ das initiale Setup inkl. Spezifikation der ersten User Stories durchzuführen (auf Basis der Dokumente/Konzepte, die der Kunde bisher hat). Solch ein „Sprint 0“ ist natürlich eher Aufwandsbasiert (die Kosten ergeben sich durch die Teamkapazität, die für diesen Sprint 0 benötigt wird) und führt dazu, dass ein erstes, priorisiertes Backlog nach Abstimmung mit den Stakeholdern (dem Kunden) existiert. Alle Folgesprints sind dann wieder werkvertraglicher Natur.

      „Bei kleinsten Dingen ewig diskutieren“: es kann sinnvoll sein, in Absprache mit dem Kunden zu definieren, dass bei der Realisierung einer User Story die „technisch einfachste Variante“ realisiert wird. So vermeidest du unnötige Diskussionen – schließlich soll ja das Devteam entscheiden, wie es die User Story technisch implementiert.

      Meetings versäumen, Server nicht rechtzeitig bestellen: nun, das kann ich jetzt so nicht nachvollziehen. Ich glaube, dass der Product Owner (in diesem Fall also auf Dienstleisterseite) schon auch die Verantwortung hat, zu den entsprechenden Meetings rechtzeitig einzuladen. Das ist ja das schöne an der agilen Vorgehensweise: du hast einen festen Rhythmus (zum Beispiel 14-tägig), der sich einpendelt und immer fix ist. Das Gleiche für das Bestellen von Servern: als Dienstleister unterstützen wir natürlich den Kunden und erinnern ihn rechtzeitig daran, dass die Server bestellt werden müssen (oder erledigen dies gleich für ihn mit, so dass er sich nicht darum kümmern muss).

      Ich gebe dir abschließend insofern Recht, dass es schwierig ist, Werkverträge für Software zu etablieren, da Werkverträge qua Gesetz durchaus für andere Dinge vorgesehen sind. Für den Kunden sind jedoch meist Planungs-/Budget“sicherheit“ wichtig sowie Gewährleistung, und ich meine hierfür kann man Lösungen bieten, die vielleicht nicht 100%-ig sind (100%ige Sicherheit gibt es sowieso nie), aber ein partnerschaftliches Miteinander auf Augenhöhe ermöglichen. Das ist gerade für Konzernumfelder sehr wichtig.

      Antworten