it-swarm-eu.dev

Umgang mit fehlgeschlagenen Sprints und Fristen

In vielen Scrum-Büchern und -Artikeln heißt es, dass ein fehlgeschlagener Sprint (wenn das Team einige Funktionen aus dem Sprint-Backlog nicht ausführt) nicht so schlimm ist, dass er von Zeit zu Zeit auftritt und tatsächlich nützlich sein kann, wenn das Team aus seinen Fehlern lernt und verbessert etwas in den folgenden Sprints. Und das Team sollte nicht dafür bestraft werden, dass es die Arbeit, zu der es sich verpflichtet hat, nicht abgeschlossen hat.

Dies sieht aus Sicht des Entwicklers großartig aus. Nehmen wir jedoch an, wir haben eine Softwarefirma " Scrum-Addicts LLC ", die etwas für ernsthafte Kunden entwickelt ("). Money-Bags Corporation "):

  1. Scrum-Addicts-Manager schlagen vor, eine Software für Money-Bags zu erstellen
  2. Sie einigen sich auf eine Liste von Funktionen, und Money-Bags fordert Sie auf, ein Versanddatum anzugeben
  3. Scrum-Addicts-Manager konsultieren ihr Scrum-Team, und das Team sagt, dass es drei Wochen dauern wird, bis alle Funktionen abgeschlossen sind
  4. Der Scrum-Addicts-Manager fügt aus Sicherheitsgründen 1 Woche hinzu, verspricht, die Software innerhalb eines Monats zu versenden, und unterzeichnet einen Vertrag mit Money-Bags
  5. Nach 4 Sprints (Versandtermin) kann das Scrum-Team nur noch 80% der Funktionen bereitstellen (aufgrund der Unerfahrenheit mit dem neuen System, der Notwendigkeit, kritische Fehler in früheren Funktionen in der Produktionsumgebung zu beheben usw.)
  6. Wie Scrum vorschlägt, ist das Produkt derzeit möglicherweise versandfähig, aber Money-Bags benötigt 100% der im Vertrag genannten Funktionen. Also brechen sie den Vertrag und zahlen nichts.
  7. Scrum-Addicts steht kurz vor dem Bankrott, weil sie kein Geld von Money-Bags erhalten haben und die Investoren von den Ergebnissen enttäuscht waren und nicht mehr bereit sind, dem Unternehmen zu helfen.

Offensichtlich möchte kein Softwareunternehmen in die Fußstapfen von Scrum-Addicts treten. Was ich über Agile und Scrum nicht verstehe, ist, wie sie Teams vorschlagen, mit Planung und Terminen umzugehen, um die oben beschriebene Situation zu vermeiden. Zusammenfassend habe ich also zwei Fragen:

Wer ist schuld?

  1. Manager, weil es ihre Aufgabe ist, die richtige Planung durchzuführen
  2. Das Team, weil sie sich dazu verpflichtet haben, mehr Arbeit zu leisten, als sie konnten
  3. Jemand anderes

Was ist zu tun?

  1. Die Manager sollten die Frist 2x (oder 3x) später als vom ursprünglichen Team geschätzt verschieben.
  2. Die Teammitglieder sollten ermutigt werden, alle Arbeiten zu erledigen, für die sie sich verpflichtet haben, indem sie Strafen für fehlgeschlagene Sprints verhängen.
  3. Das Team sollte Scrum fallen lassen, da es nicht den Unternehmensfristen entspricht
  4. Wir sollten alle die Softwareentwicklung einstellen und uns einem Kloster anschließen
  5. ???
80
Andre Borges

Ich sehe in Ihrem Beispiel mehrere grundlegende Managementprobleme:

  • wenn ein Scrum-Addicts-Manager einen Vertrag mit "harten Fristen" unterzeichnet, aber in einer Situation, in der "ein neues System involviert ist", nur eine Sicherheitsmarge von 33% hinzufügt, ist das ziemlich rücksichtslos.

  • die Verfügbarkeit der Bereitstellung von mindestens x% der Funktionen nach einem Monat hätte genutzt werden können, um einen Vertrag auszuhandeln, bei dem der Kunde das Geld zumindest teilweise zahlt, wenn er zum Stichtag nur 80% der Funktionen erhält. Ein Alles-oder-Nichts-Vertrag ist etwas, von dem weder der Softwareanbieter noch der Kunde profitieren werden - dies bedeutet nicht nur 0 Geld für den Anbieter, sondern auch 0 Funktionen für den Kunden. Und mit einer Alles-oder-Nichts-Entwicklungsmethode wie "Wasserfall" können Sie nur solche Verträge abschließen. Ein agiler Ansatz bietet zusätzliche Möglichkeiten.

  • ein Blick auf die Ergebnisse der ersten ein oder zwei Sprints hätte dem Manager klar machen müssen, dass das Team die Frist nicht einhalten kann. Er hätte also frühere Maßnahmen ergreifen und die verbleibenden Aufgaben und Funktionen neu priorisieren oder versuchen sollen, früher mit dem Kunden neu zu verhandeln. Beispielsweise hätte der Manager versuchen können, den Umfang einiger der verbleibenden Funktionen zu verkleinern, sodass das Team alle im Vertrag genannten Funktionen hätte liefern können, jedoch jeweils in einem reduzierten Umfang.

Wenn sich herausstellt, dass eine Aufgabe länger dauert als gedacht, kann Sie keine Entwicklungsmethode davon abhalten. Ein agiler Ansatz wie Scrum bietet dem Management jedoch mehr Möglichkeiten, um zu steuern, was in dieser Situation geschieht. Wenn sie diese Möglichkeiten nicht nutzen, ist es eindeutig ihre Schuld, nicht die des Teams, nicht die Schuld von "Scrum" und nicht die Schuld des Kunden, weil "er Agilität nicht akzeptiert".

133
Doc Brown

Eine der Wertaussagen des " Manifest für agile Softwareentwicklung " lautet:

Kundenzusammenarbeit über Vertragsverhandlungen

Die Tatsache, dass Scrum-Addicts LLC einen Vertrag ausgehandelt hat, anstatt eine Zusammenarbeit mit einem Kunden aufzubauen, lässt mich deren Agilität in Frage stellen.

Eines ist klar: Beweglichkeit muss von JEDEM akzeptiert werden. Agilität ist nicht nur für Entwickler. Manager und Kunden müssen auch die Werte von Agile Manifesto akzeptieren. Wenn Kunden Agilität nicht akzeptieren und dennoch starre Verträge und minimale Zusammenarbeit benötigen, verwenden Sie entweder keine Agilität oder finden Sie bessere Kunden.

Es ist die Schuld des Kunden, dass er mit einer fristgerechten Entwicklung in seiner Vertragsblase eingeschlossen ist.

66
Euphoric

Wer ist schuld?

Manager, Rechtsabteilung, Buchhalter - treffen Sie Ihre Wahl ...

Ich weiß, dass das Beispiel etwas erfunden ist, aber die Tatsache, dass das Unternehmen ohne einen Cent weggehen könnte, wenn es nicht 100% zufrieden wäre, hätte sofort Alarmglocken läuten müssen, ebenso wie das Mischen von Wasserfall und agilem Denken.

Kunden möchten ihren Kuchen haben und ihn essen - sie akzeptieren gerne Wasserfall, Mini-Wasserfall, Agilität und La-La-Land, solange sie Produkt X für $ Y bis zum Datum Z erhalten.

Agile Entwicklung nbedingt erforderlich Das Entwicklungsteam und der Kunde müssen sich aus methodischer Sicht auf derselben Seite befinden. Das Denken, dass Unterschiede in der Kultur nur beim Waschen zum Vorschein kommen, ist Wunschdenken.

15
Robbie Dee

IT-Projekte befassen sich mit Unbekannten ; Einige dieser Unbekannten sind sogar unbekannte Unbekannte . Was bedeutet das?

Nehmen Sie zum Beispiel eine Spielzeugbrücke für Ihre Modelleisenbahn. Ihnen sind alle Parameter bekannt:

  • Sie wissen, wie groß das Tal ist

  • Sie kennen das Material der Berge, ihre Höhe, Stabilität usw.

  • Sie wissen, wie viel Material Sie benötigen

  • Sie wissen aus früheren "Projekten", wie lange Sie gebraucht haben, um ähnliche Dinge zu bauen

Es gibt viele Variablen, die Ihre Berechnung der Investition von Freizeit und Geld beeinflussen. Aber man könnte ohne nachzudenken sagen, ob es nächstes Wochenende fertig ist.

Gehen Sie mit dem Beispiel noch einen Schritt weiter:

  • Angenommen, Sie bauen die Brücke nicht für Ihre eigene Modelleisenbahn, sondern für einen völlig Fremden: Ihre Aufgabe ist es, eine Eisenbahnbrücke zwischen zwei Bergen zu bauen

  • Angenommen, Sie haben fast keine Informationen vor der Modelllandschaft

  • Die Information über die Landschaft ist, das heißt zwei Berge, die nicht zu groß erscheinen

  • Die Konsistenz des Berges liegt zwischen Fels und Gelee

  • Die Gesamtkosten betragen maximal 10 $

  • Der Arbeitsplatz ist komplett dunkel und es gibt keine Chance auf Licht: Sie haben nur eine Schachtel mit 8 Streichhölzern

  • Die Frist beträgt 3 Stunden

Das wäre die Analogie zu einem IT-Projekt. Sie haben Erfahrung im Brückenbau und es ist einfach, auf bekanntem Gelände zu laufen. Was es schwer macht, ist die Dunkelheit . Es gibt viele Dinge, die Sie kaum vorhersagen können: Die Maße der Berge sind erst bekannt, nachdem Sie einige Zeit im Dunkeln gestochert haben. So ist die Konsistenz der Berge. Daraus können Sie Schätzungen vornehmen, wie lange Sie brauchen und wie viel es kosten wird. Hier sind die Unbekannten Dinge, die Sie zu Beginn des Projekts nicht kennen, wie das konkrete Terrain usw. Aber es gibt Dinge, die Sie nicht vorhersehen können, selbst mit den meisten Erfahrungen und konservativsten Schätzungen. Diese Dinge sind die unbekannten Unbekannten , die ein bisschen Chaos ertragen.

Das sollte jedes IT-Unternehmen wissen. Sie müssen mit dem Projektrisiko umgehen.

1) Es gibt verschiedene Möglichkeiten, um das (finanzielle) Risiko zu minimieren: Das Geschäft kann beinhalten, dass der Kunde für jedes Arbeitsinkrement bezahlt. Nach der Lieferung von Inkrement 1 muss also ein Teilsatz gezahlt werden. Solange Scrum-Addicts LLC liefert, besteht nur ein minimales finanzielles Risiko. Je feinkörniger Sprintziele geplant sind, desto geringer ist das Gesamtrisiko jedes Sprints. Das heißt, wenn Money-Bags Corporation 80% des Vertrags erhalten hat, sollten sie mindestens 80% des Vertragswerts bezahlen. Wenn sie sich nach einem fehlgeschlagenen Sprint weigern zu zahlen, ist das Risiko nicht so hoch wie die Weigerung, 100% zu zahlen.

2) Scrum-Addicts LLC hat ein Problem mit ihren Entwicklern

Scrum-Addicts-Manager konsultieren ihr Scrum-Team, und das Team sagt, dass es 3 Wochen dauern wird, bis alle Funktionen abgeschlossen sind. Scrum-Addicts-Manager fügt aus Sicherheitsgründen 1 Woche hinzu, verspricht, die Software innerhalb eines Monats zu versenden und unterzeichnet einen Vertrag mit Geldsäcken

Dies deutet darauf hin, dass a) die Entwickler keine Erfahrung mit Scrum haben oder b) sie Scrum falsch machen. Je länger Teams mit Scrum arbeiten, desto besser sind ihre Schätzungen. Wenn die Teams Schätzungen vornehmen und der Manager einen "Puffer" als "Sicherheit" hinzufügt , scheint der Manager es besser zu wissen als das Team, das ein - ist. schlechtes Zeichen. Wenn Sie ein erfahrenes Team haben, ist kein "Managerbuffer" erforderlich. Das Team hat diesen bereits in die Schätzung einbezogen. Die Idee ist, je mehr Sprints das Team zusammengearbeitet hat, desto mehr kennt das Team seine Stärken und Schwächen und verfügt über einige Metriken, um realistische Schätzungen vorzunehmen. Natürlich gibt es - wie bereits erwähnt - die unbekannten Unbekannten , die Schätzungen schwer machen; oder zumindest ungenau. Aber auf lange Sicht sollten die Schätzungen immer besser werden.

Wer ist schuld?

1) Management

Wie oben gesagt: Das Risikomanagement ist eindeutig fehlerhaft. Wenn das Unternehmen kurz vor dem Bankrott steht, hat es das Unternehmen verdient. Wenn Sie in einem solchen Unternehmen arbeiten: gehen Sie!

2) Das Team

Auch wenn das Management absolut dumm ist, hätte sich das Team gegen ein solches Projekt aussprechen sollen. Ein guter Manager sollte die Risiken kennen. Ein guter Entwickler sollte jedoch auf Risiken hinweisen. Und vor allem: Das Team sollte sich frühzeitig melden, wenn etwas ausfällt.

Was ist zu tun?

Jetzt: Bring Geldsäcke vor Gericht

Für die Zukunft: Machen Sie solche Verträge nicht

Scrum ist nicht für Managementfehler verantwortlich. Scrum wurde basierend auf der Erfahrung vieler fehlgeschlagener IT-Projekte entwickelt. Es kann weder einen Ausfall verhindern noch die Inkompetenz von Teams oder Management heilen. Die Grundidee ist:

  • kommunikationswege zu strukturieren (wer spricht mit wem wann über was)

  • um Entwickler zu ermutigen, Fehler frühzeitig zu melden

  • probleme in Aufgaben und Unteraufgaben zu unterteilen

  • zeit und Kapazitäten zu strukturieren (wer arbeitet wann an was)

  • um die Aufgaben auf die Zeitfenster zu verteilen

  • das Unvorhersehbare etwas vorhersehbarer machen (Poker planen)

oder insgesamt: um das Risiko zu minimieren.

Scrum ist ein Werkzeug wie ein Hammer. Ob es ein gutes Werkzeug ist, hängt von Ihrem Wissen ab, wie man es benutzt. Aber manchmal passt ein Schraubenzieher besser. Es liegt an dir.

12
Thomas Junk

Zunächst einmal: "Wer ist schuld?" ist die falsche Frage zu stellen. Schuldzuweisungen machen Spaß und werden wahrscheinlich dazu führen, dass sich alle außer den beschuldigten Personen erleichtert fühlen (im Sinne von "Hey, es ist nicht meine Schuld, der Chef hat es gesagt!"), Aber es ist keine produktive Nutzung Ihrer Zeit und kann tatsächlich kontraproduktiv sein und die Moral der Mitarbeiter beeinträchtigen.

Eine bessere Sichtweise ist "Was hat die Verzögerung verursacht?". War es mangelnde Erfahrung in der Technologie? Kritische Fehler, die beim Testen/QS nicht erkannt wurden? Fehlende Tests/Qualitätssicherung? Zu optimistisch in der Schätzung? Ohne die nicht so optimistischen Schätzungen des Teams zu berücksichtigen? Jemand wurde von einem Bus angefahren? Was auch immer die Ursache sein mag, die nächste Frage lautet: "Wie stellen wir sicher, dass dies nicht noch einmal passiert?". In einigen (hoffentlich seltenen) Fällen könnte die Antwort darauf lauten: "So und so loswerden". Wenn Sie jedoch mit "Ich muss den Verantwortlichen bestrafen" beginnen, ist es unwahrscheinlich, dass Sie die Mehrheit der Fälle sehen wo es nicht die richtige Lösung ist.

Innerhalb des Projekts sind Sie bereits versenkt. Die Frist ist gekommen und gegangen, Sie haben den Kunden gewarnt, sobald klar war, dass sie verrutschen würde (weil Sie das getan haben, richtig? Wenn nicht, ist das Teil des Problems), und jetzt muss es behandelt werden, wie auch immer es formuliert wurde im Vertrag (es ist tatsächlich im Vertrag festgelegt, oder?). Im Allgemeinen sollte dies bedeuten, mit dem Kunden zu verhandeln, wie Sie das liefern, was fehlt. Viele Leute denken gerne an einen Vertrag als etwas, das nicht geändert werden kann, aber entweder a) den Vertrag fallen lassen und nicht das haben, was Sie gekauft haben, b) das Unternehmen wegen Vertragsbruch verklagen und viel Geld vor Gericht ausgeben, und c) Verhandlungen darüber, wie sie ihr Produkt mit möglichst geringem Aufwand erhalten können, wählen die meisten Unternehmen c.

Mit Blick auf die Zukunft sollten Sie, bevor Sie einem Kunden einen Preis/eine Frist angeben, die Risiken analysieren, die mit einer verspäteten Frist oder einer Kostenüberschreitung verbunden sind (was sind mögliche Ursachen für so etwas? Welche Ursachen können Sie irgendwie abmildern und welche können Sie nicht und nur müssen planen) und diese Informationen verwenden, um zu entscheiden, was Sie versprechen werden. Wenn es sich um einen Fall handelt, in dem es zu 100% oder gar nichts ist, werden Sie offensichtlich höhere Preise und längere Fristen angeben, da das Risiko höher ist.

Sie werden feststellen, dass ich in dieser ganzen Antwort nicht über Agile gesprochen habe. Das liegt daran, dass es an dieser Stelle nicht wirklich wichtig ist (ich werde für eine Sekunde die Beteiligung des Kunden an Scrum vergessen, obwohl dies sehr, sehr wichtig ist). Sie werden mit diesem Problem in Agile, Waterfall oder einem anderen von Ihnen verwendeten Entwicklungsprozess konfrontiert sein. Ja, Agile soll Ihnen helfen, Risiken besser zu managen, indem Sie sehen, ob sie früher zu tatsächlichen Problemen geworden sind, und den Kunden in den Prozess selbst einbeziehen, damit er immer informiert ist, aber es ist kein Allheilmittel.

9
Iker

Das Entwicklungsparadigma stimmt nicht mit dem Vertragsparadigma überein. Im Idealfall würde sich die Art und Weise, wie Verträge geschrieben werden, ändern, aber das ist unwahrscheinlich. Selbst wenn Sie Scrum fallen lassen würden, hätten Sie immer noch Überraschungen und versäumte Fristen (nur würden Sie wahrscheinlich viel später sein, weil Sie das ganze Design im Voraus gemacht haben und alles falsch war !!).

Mit oder ohne Änderung der Art und Weise, wie Verträge geschrieben werden, versenden Sie, was Sie arbeiten . Erfüllen Sie dann den Vertrag, indem Sie einen Entwicklungszyklus durchlaufen, um die Funktionen fertigzustellen, die Sie nicht ausgeführt haben.

Ist es gut, dass Sie nicht alles geliefert haben, was Sie an dem Tag versprochen haben, den Sie versprochen haben? Nein, aber Ihr Kunde wird viel glücklicher sein, wenn Sie etwas liefern können, das pünktlich funktioniert, und dann den Rest schnell danach liefern können, als wenn Sie einfach zu spät kommen und überhaupt nichts zu geben haben.

4
RubberDuck

Erstens ist dies ein Problem bei jeder Entwicklungsmethode. Zumindest mit einem iterativen Entwicklungssystem müssen Sie dem Kunden am Ende der Frist etwas zeigen, was möglicherweise ausreicht, um eine Erweiterung für die Fertigstellung des Produkts zu erhalten (auch wenn der Kunde nicht mehr zahlt!).

Es gibt Fälle, in denen eine Frist eine Frist ist. Stellen Sie sich jedoch vor, Sie schreiben ein Spiel und es muss unbedingt rechtzeitig zu den Weihnachtsferien veröffentlicht werden. Das falsch zu machen hat so manche Firma bankrott gemacht!

Für agile Methoden, die eine bestimmte Anzahl von Funktionen bis zu einem bestimmten Datum ausführen müssen, ist Scrum wahrscheinlich nicht die beste Methode (da ich immer festgestellt habe, dass Scrum Dev langsamer macht und nicht genügend Agilität zulässt, um den Prozess zu ändern, wenn erforderlich.

Unabhängig von der Methodik müssen Sie einen Rückstand an erforderlichen Funktionen einrichten, um den Fortschritt sichtbar zu machen. Fortschritte pro Sprint sind nicht gut genug. Sie werden nicht wissen, ob Sie das endgültige Ziel erreichen. Eine Methode im Kanban-Stil wäre daher besser: Stellen Sie alle Funktionen auf der linken Seite ein und arbeiten Sie sie durch das System, um den Fortschritt bis zur Fertigstellung anzuzeigen.

Dies konzentriert die Gedanken der Menschen auf das, was noch zu tun ist, auf eine Weise, die Scrum nicht handhabt, und ermöglicht es anderen als dem Entwicklerteam, zu sehen, was noch übrig ist und ob Sie das Ziel wahrscheinlich erreichen (und so die Erwartungen der Kunden frühzeitig zu verwalten) oder vereinbaren Sie diese Überstundenboni, bevor sie benötigt werden).

Scrum ist ein System, das für immer weiter spielt und ständig etwas definiert und verfeinert. Es ist einfach nicht für diese Art der Entwicklung geeignet. Andere können dieses System verwalten und trotzdem das iterative Entwicklungskonzept beibehalten, Kanban ist eines davon, Crystal ein anderes. Es ist jedoch wichtig zu verstehen, dass Sie nicht agil sind, wenn Sie Scrum religiös folgen. Jedes echte agile System sollte in der Lage sein, sich zu verwandeln, um mit diesen speziellen Problemen fertig zu werden. Deshalb wurde es in erster Linie als agil bezeichnet. Es geht darum, das zu erledigen, was getan werden muss, und wenn eine feste Frist Teil davon ist, sollten Sie dies tun Berücksichtigen Sie dies bei Ihrer Arbeitsweise.

4
gbjbaanb

In vielen Scrum-Büchern und -Artikeln heißt es, dass ein fehlgeschlagener Sprint (wenn das Team einige Funktionen aus dem Sprint-Backlog nicht ausführt) nicht so schlimm ist, dass er von Zeit zu Zeit auftritt und tatsächlich nützlich sein kann, wenn das Team aus seinen Fehlern lernt und verbessert etwas in den folgenden Sprints. Und das Team sollte nicht dafür bestraft werden, dass es die Arbeit, zu der es sich verpflichtet hat, nicht abgeschlossen hat.

Die Art und Weise, wie Sie diese Art von Verhalten "bestrafen", besteht darin, den Arbeitsaufwand zu begrenzen, den diejenigen, die nicht fertig sind, für den nächsten Sprint übernehmen können. Die Chancen, an coolen Sachen zu arbeiten, verschwinden. Die Belohnung für gute Arbeit ist mehr Arbeit.

Dies sieht aus Sicht des Entwicklers großartig aus. Nehmen wir jedoch an, wir haben ein Softwareunternehmen "Scrum-Addicts LLC", das etwas für ernsthafte Kunden entwickelt ("Money-Bags Corporation"):

Scrum-Addicts-Manager schlagen vor, eine Software für Money-Bags zu erstellen. Sie einigen sich auf eine Liste von Funktionen, und Money-Bags bittet um Angabe eines Versanddatums. Scrum-Addicts-Manager konsultieren ihr Scrum-Team. Das Team sagt, dass dies 3 Wochen dauern wird -lange Sprints, um alle Funktionen zu vervollständigen Der Scrum-Addicts-Manager fügt aus Sicherheitsgründen 1 Woche hinzu, verspricht, die Software in 1 Monat zu versenden und unterzeichnet einen Vertrag mit Money-Bags. Nach 4 Sprints (Versandfrist) kann das Scrum-Team nur noch 80% liefern Anzahl der Funktionen (aufgrund der Unerfahrenheit mit dem neuen System, der Notwendigkeit, kritische Fehler in früheren Funktionen in der Produktionsumgebung zu beheben usw.) Wie Scrum vorschlägt, ist das Produkt derzeit möglicherweise lieferbar, aber Money-Bags benötigt 100% von Funktionen, wie im Vertrag erwähnt. Also brechen sie den Vertrag und zahlen nichts.

Scrum-Addicts steht kurz vor dem Bankrott, weil sie kein Geld von Money-Bags erhalten haben und die Investoren von den Ergebnissen enttäuscht waren und nicht mehr bereit sind, dem Unternehmen zu helfen.

Wenn ich Ihnen am Montag 100 $ wette, dass es am Donnerstag regnen wird und es erst am Freitag regnet, haben Sie Recht, mein Geld zu nehmen. Wenn Sie keine Chance zum Spielen haben, sondern eine Wettervorhersage, benötigen wir einen Vertrag, mit dem ich Ihnen am Dienstag eine aktualisierte Vorhersage geben kann.

Offensichtlich möchte kein Softwareunternehmen in die Fußstapfen von Scrum-Addicts treten. Was ich über Agile und Scrum nicht verstehe, ist, wie sie Teams vorschlagen, mit Planung und Terminen umzugehen, um die oben beschriebene Situation zu vermeiden.

Überlegen Sie, warum MB ihren Ball nehmen und nach Hause gehen möchte. MB hat zu Beginn nicht verlangt, dass die Arbeit in einem Monat erledigt wird. SA versprach 100% der kritischen Funktionen in einem Monat und lieferte nicht. SA setze die Frist nicht MB. SA = sogar willkürlich eine Woche zur Frist hinzugefügt. Warum ist dies eine Frist?

Gelegentlich geben Softwarefirmen im Wettbewerb um Arbeit der Versuchung nach, den Mond zu zeigen und zu versprechen. Profis stellen sorgfältig fest, ob überhaupt ein Mond benötigt wird. Welches ist der kritischere Bedarf an MoneyBags? 100% der Funktionen oder ein funktionierendes Produkt in einem Monat? Wissen sie überhaupt, was wirklich kritisch ist? Gibt es eine bevorstehende Veranstaltung, die einen harten Termin festlegt?

Wenn ich Scrum-Addicts wäre, die diesen Vertrag aushandeln, würde ich viel mehr über die Geschäftsanforderungen von Money-Bags wissen und den Vertrag so strukturieren wollen, dass er so viel Flexibilität bietet, wie Money-Bags bietet. Ich würde ihnen beibringen, wie der agile Prozess funktioniert, damit sie wissen, was sie von uns erwarten können.

Auf diese Weise würden sie nicht erwarten, dass in einem Monat plötzlich alles perfekt funktioniert, sondern das erste Ergebnis in 1 bis 2 Wochen bewerten.

Zusammenfassend habe ich also zwei Fragen:

Wer ist schuld? Manager, weil es ihre Aufgabe ist, die richtige Planung durchzuführen
Das Team, weil sie sich dazu verpflichtet haben, mehr Arbeit zu leisten, als sie konnten
Jemand anderes

Jeder hätte diese Travestie stoppen können, bevor wir einen Monat später waren.

Ich könnte sogar Money-Bags Corp beschuldigen, ein Team eingestellt zu haben, das offensichtlich einen Wasserfallprozess betrügerisch als agil darstellt. Der Vertrag selbst macht deutlich, dass dies nicht agil ist. Die Planung in einem Monat macht es nicht agil.

Wenn Sie darauf bestehen, dass es agil ist, ist es agil mit nur einem Sprint, der einen Monat lang ist. Was ich ja nicht empfehlen würde, denn das ist wieder dasselbe wie ein Wasserfall.

Was ist zu tun?

Wie wäre es mit Agilität? Bei jedem Sprint etwas liefern? Feedback vor Ablauf der Frist erhalten? Einwöchige Sprints? Wie wäre es mit einer Neuverhandlung des drakonischen Vertrags in dem Moment, in dem Sie vermuten, dass die Frist in Gefahr ist, anstatt sich zu verstecken und zu beten? Zumindest können Sie aufhören, Zeit mit einem zum Scheitern verurteilten Projekt zu verschwenden, und einen vernünftigeren Kunden finden.

Die Manager sollten die Frist 2x (oder 3x) später als vom ursprünglichen Team geschätzt verschieben.

Deadline-Multiplikatoren sind ungefähr so ​​nützlich wie das Einstellen Ihrer Uhr um 15 Minuten zu früh, damit Sie nie zu spät kommen. Sie können sich nur so lange täuschen, bis Sie erkennen, was Sie vorhaben.

Frühe Schätzungen sind falsch. Versuchen Sie zu erfassen, wie falsch. 5 Wochen, ein paar Wochen geben oder nehmen ist ein einfacher Ausdruck, mit dem Sie ausdrücken können, wie unsicher das Fertigstellungsdatum wirklich ist. Anstatt zu versuchen, genau zu raten, raten Sie, wie wild Ihre Vermutung ist. Machen Sie echte Arbeit und erhalten Sie echte Daten. Dann können Sie Schätzungen mit einem engeren Bereich vornehmen. Ein bis zwei Wochen sind genug Zeit, um dies zu tun.

Die Teammitglieder sollten ermutigt werden, alle Arbeiten zu erledigen, für die sie sich verpflichtet haben, indem sie Strafen für fehlgeschlagene Sprints verhängen.

Teammitglieder sollten ermutigt werden. Fehlgeschlagen, begangen oder auf andere Weise. Anstatt künstliche Konsequenzen wie Bestrafungen oder sogar Boni (Zuckerbrot und Peitsche) zu konstruieren, haben Studien gezeigt, dass Menschen, die kreative Arbeit wie Programmieren leisten, am besten reagieren, wenn drei Dinge vorgesehen sind: Autonomie, Meisterschaft und Zweck.

Daniel Pink hat ein TED-Gespräch darüber. Das Gespräch handelt von Motivation, die nicht agil ist, aber ich habe leicht gesehen, wie man diese Punkte agil zuordnet:

Autonomie - Ich möchte mein eigenes Leben lenken - Lassen Sie mich Arbeit aus dem Rückstand auswählen.
Meisterschaft - Ich möchte in etwas, das wichtig ist, besser werden - Kundenfeedback.
Zweck - Ich möchte Teil von etwas sein, das größer ist als ich selbst - Ein kollaboratives Team.

Das Team sollte Scrum fallen lassen, da es nicht zu den Unternehmensfristen passt. Scrum kann eine Frist genauer treffen als Wasserfälle. Bei gegebener Frist kann Scrum es einhalten. Je nach Zeit, Merkmal und Können kann es nur 1 von 47 Merkmalen erfüllen, aber es kann es erfüllen.

Ein agiles Projekt kann so extrem gestaltet werden, dass es jede Nacht, wenn das Team nach Hause geht, versandbereit ist. Dies erscheint albern, es sei denn, Sie denken, der Versand fordert den Kunden auf, zu testen und Feedback zu geben. Je früher dies geschieht, desto eher können Sie Anpassungen vornehmen. Dies trifft jede mögliche Frist. Nur nicht jede Funktion. Aber es lenkt Sie zu den Funktionen, die wichtig sind.

Wir sollten alle die Softwareentwicklung einstellen und uns einem Kloster anschließen

Richtig, als würde mich das Einsperren in einem Raum außerhalb des wirklichen Lebens dazu bringen, WENIGER Code zu schreiben.

Ich habe diese Antwort auf die Größe reduziert. Wenn Sie neugierig sind, lesen Sie den Bearbeitungsverlauf.

1
candied_orange

Jeder muss agil sein. Was auch immer Sie sich entscheiden, sehen Sie so aus, wer macht was, wie, wann, wo und warum von allen Parteien. Agile Kunden, Management und Entwickler.

Sie können ein Versanddatum nicht zu weit in die Zukunft angeben. Sie geben eine Schätzung.

Jemand musste die Erwartungen des Kunden erfüllen. Der Grund, warum Sie sich nicht zu viele Sorgen machen, dass ein paar Sprints zurückfallen, ist, dass Sie sich anpassen, um zu verhindern, dass das gesamte Projekt zurückfällt. Wenn Sie nach ein oder zwei Sprints zu dem Schluss kommen, dass Sie das "Versanddatum" nicht einhalten werden, teilen Sie dies dem Kunden mit.

Was willst du jetzt machen? Entfernen Sie nicht benötigte Funktionen oder verschieben Sie das Datum. Wenn Sie pünktlich liefern könnten, würden Sie. Zögern Sie nicht, schlechte Nachrichten zu bringen.

Wer weiß, bei einigen Projekten können Sie früher versenden.

Sie können nicht agil sein, wenn der Client nicht möchte.

0
JeffO

Tor

Ich glaube, die folgenden zwei "Metriken" sollten die Grundlage für jede Geschäftsentscheidung sein:

  • ist die Arbeit rentabel (für den Kunden)
  • arbeiten wir so effizient wie möglich?

Diese sind ziemlich universell. Natürlich wird es sehr schnell komplizierter, zum Beispiel geht es bei rentabler Arbeit darum, dass das Produkt das Richtige tut, der Benutzer das Produkt verwenden kann, das Produkt korrekt vermarktet wird usw. - für viele von diesen "Scrum-Addicts LLC "trägt keine Verantwortung.

Problem

Der Vertrag konzentriert sich nicht auf die oben genannten Ziele. Es gibt eine "Alles oder Nichts" -Klausel - alles erledigen und bezahlt werden oder nichts erledigen und nicht bezahlt werden. Dies bezieht sich jedoch nicht direkt auf die Wertschöpfung. Ein weiterer Nachteil, der folgt: Jetzt müssen wir Zeit und Geld investieren, um sicherzustellen, dass der Vertrag eingehalten wird. Warum um alles in der Welt sollten wir dieses Geld ausgeben wollen? Wie hilft es, sicherzustellen, dass ein Vertrag erfüllt wird, wenn sich die Anforderungen in der Zwischenzeit geändert haben und wir festgestellt haben, dass die bestellte Software keinen Wert schafft? Es geht einfach mehr Geld den Bach runter! Jetzt gibt es natürlich einen Grund für dieses Verhalten:

  • Kulturell sind wir es gewohnt, solche Dinge zu kaufen. Wir erwarten, dass wir Software wie ein Auto kaufen: Wählen Sie eine Konfiguration, erhalten Sie einen Preis und eine Frist und sind Sie sehr unglücklich, wenn diese beiden nicht eingehalten werden.
  • wir wollen Risiko und Rechenschaftspflicht auslagern
  • wir wollen Stabilität, es hilft bei der Planung und wir fühlen uns besser (und auch unser Kunde, was ein wichtiger Aspekt ist!)

Letztendlich müssen wir einen Kompromiss wählen, der es uns ermöglicht, unsere Ziele so gut wie möglich zu erreichen.

So sollte es funktionieren

  • einen Vertrag für Dienstleistungen und Arbeit haben anstatt für ein Produkt
    • muss relativ kurzfristig kündbar sein
  • arbeiten Sie eng zusammen, um eine optimale Effizienz zu gewährleisten
  • beziehen Sie alle erforderlichen Parteien ein, sowohl von "Scrum-Addits LLC" als auch von "Money-Bags Corporation" - ein "einzelner Ansprechpartner", der alle Informationen tunnelt, funktioniert nicht hier zu arbeiten

nun, ich sagte im Grunde nur "sei agil". Hier ist der Grund:

  • prozess & Vertrag sind optimiert, um so viel Geld wie möglich für das Ziel auszugeben
  • sie müssen dem Auftragnehmer vertrauen, dass er seine Arbeit erledigt, und Sie müssen nicht viel Geld investieren, um zu überprüfen, ob er der Arbeit gewachsen ist.
  • die Möglichkeit, Ihren Auftragnehmer zu verklagen, wenn Ihre Erwartungen/Ihr Vertrag nicht erfüllt werden, hilft normalerweise nicht weiter, da dies mehr kostet als nur das Fallenlassen. Einige der Hauptanliegen hierbei sind die Markteinführungszeit. Sie werden höchstwahrscheinlich viel mehr Geld/Geschäft verlieren, wenn Sie vor Gericht gehen, als Sie bekommen.
    • am Ende des Tages müssen Sie nur einige Risiken selbst tragen.
0