Ist es falsch, Agile zu verwenden, wenn sich die Anforderungen der Kunden überhaupt nicht ändern?

12

Ich habe in letzter Zeit viele Posts gesehen, in denen es heißt, dass einer der Hauptgründe für die Verwendung von Agile darin besteht, dass Kunden häufig die Anforderungen ändern.

Nehmen wir jedoch an, die Kunden ändern die Anforderungen nicht häufig . Tatsächlich haben die Kunden zwar feste Anforderungen, die vielleicht etwas vage sind (aber nichts Unangemessenes), aber ich benutze trotzdem Agile.

Der Grund, warum ich Agile einsetze, ist, dass die Software so komplex ist, dass es Details gibt, Probleme, die ich erst erkennen würde, wenn ich sie tatsächlich sehe. Ich könnte einen umfassenden Planungsansatz wie Waterfall durchführen, aber dann würde es einige Monate dauern, bis alle High-Level-Designs und Low-Level-Codierungssignaturen abgeschlossen sind. Es gibt jedoch ein sehr spezifisches, festes Architekturdesign für das System.

Meine Frage ist: Wäre dies als schlecht, Cowboy-Codierung, Anti-Muster, etc.? Müssen wir den Wasserfall einsetzen und so viel wie möglich detailliert planen, bevor wir mit dem Codieren beginnen, wenn die Anforderungen stabil sind, anstatt diese Mentalität in Agile zu verwenden?

EDIT: Das Wichtigste dabei ist, dass wir den Kunden KEINE Schuld für sich ändernde Anforderungen geben können. Angenommen, die Kunden haben uns auf ein sehr konkretes Problem hingewiesen, geben uns eine Wunschliste mit sehr vernünftigen Details und lassen uns in Ruhe (dh die Kunden haben ihre eigenen produktiven Dinge zu tun, nerven sie nicht mehr) ende, wenn du einen minimalen funktionierenden Prototyp hast). Wäre es falsch, in diesem Szenario Agile zu verwenden?

agile development-process

— InformedA
quelle

2

@randomA: Eigentlich sollte man, meiner Meinung nach, nie einen reinen Wasserfall probieren, nur wenn man ein funktionierendes Produkt schaffen möchte, das mehr als eine Woche Arbeit erfordert.

— Doc Brown

10

Bitte geben Sie mir Ihre Kunden

— Razethestray

7

Ich werde Ihren Kunden 2x mehr geben als @razethestray

— Euphoric

2

Wenn Ihr Kunde nicht täglich gestört werden möchte, lernen Sie, wie Sie effektiv mit ihm kommunizieren. Anstatt beispielsweise (wahrscheinlich falsche) Annahmen über unklare Punkte zu treffen, sammeln Sie Fragen in einer Liste und senden Sie Ihrem Kunden die Liste in regelmäßigen Abständen. Noch besser: Vereinbaren Sie ein Treffen, um die Punkte zu besprechen. Wenn die Anforderungen so klar sind, dass die Liste leer bleibt: keine Besprechung (aber ich denke, es wird nicht). Wenn Sie anfangen, falsche Annahmen in Ihre Software zu implementieren, müssen Sie viel mehr tun, um dies später zu ändern.

— Doc Brown

3

@randomA: Sie können Ihren Kunden für einige Zeit glücklich machen, indem Sie nichts fragen. Wenn Sie dann das letzte Ergebnis liefern, sind Sie sehr unglücklich, da Sie die Anforderungen so sehr verfehlt haben, dass Sie Ihr Programm wegwerfen und loslegen können von Anfang an (was der Kunde nicht bereit ist zu zahlen). Oder du machst ihn ein wenig unglücklich, indem du ihn zwischendurch genug bittest, um das richtige Programm zu erstellen, aber am Ende bist du sehr glücklich, wenn das Programm tatsächlich das tut, was er will und er bekommt, wofür er bezahlt hat. Treffen Sie Ihre Wahl.

— Doc Brown

16

Wäre dies als schlecht, Cowboy-Codierung, Anti-Muster.

Kurze Antwort: nein. "Agil" richtig zu machen, bedeutet nicht "keine Planung", es bedeutet nicht, Dinge zu überanalysieren.

Einer der Hauptgründe für den Einsatz von Agile ist, dass Kunden häufig die Anforderungen ändern.

Das ist eine vereinfachende Aussage. Bei "Ändern von Anforderungen" geht es auch darum, wie sich das Verständnis des Teams für die Anforderungen ändert. Und es geht darum, wie sich die Prioritäten des Kunden in Bezug auf die Anforderung ändern, wenn er tatsächlich einige Versionen der Software sieht.

In der Tat funktioniert "agil" meiner Meinung nach am besten genau in der von Ihnen beschriebenen Situation - der Kunde hat ein gutes Wissen über seine Gesamtanforderungen, Sie können einen allgemeinen Plan daraus erstellen, Ihren Rückstand mit vielen "User Stories" füllen und haben bereits genug Informationen, um die richtige Systemarchitektur zu wählen. Die kurzen Iterationen einer agilen Entwicklungsstrategie helfen dann dabei, die "vagen Anforderungen" präziser zu gestalten, mit viel Feedback, wenn Sie noch in die richtige Richtung gehen. Außerdem erhalten Sie frühzeitig Rückmeldung über den tatsächlichen Aufwand und die tatsächlichen Kosten (was bei einem Wasserfall-Ansatz immer noch scheitern kann, selbst wenn Sie jede einzelne Anforderung genau kennen).

— Doc Brown
quelle

3

"Wasserfall" richtig zu machen, bedeutet nicht "alles planen", sondern Dinge nicht zu unteranalysen.

— Giorgio

1

@Giorgio: "waterfall" richtig zu machen bedeutet, es nicht anzuwenden, wenn die Anforderungen "ein bisschen vage" sind und "die Software so komplex ist, dass es Details gibt, Probleme, die ich erst erkennen würde, wenn ich tatsächlich mit ihnen konfrontiert werde" (zitiere aus dem ursprüngliche Frage).

— Doc Brown

6

In dieser Situation agil zu sein, ist immer noch eine sehr gute Idee. Agile bietet viele Vorteile, von denen nur eines das regelmäßige Feedback des Kunden und die Fähigkeit ist, auf sich ändernde Anforderungen zu reagieren.

Einer der Hauptgründe, warum Wasserfallprojekte für ihr Scheitern berüchtigt sind, ist das „fast abgeschlossene“ Problem - das Testen von Fehlerhäufchen am Ende, so dass ein unlösbares Produkt übrig bleibt und keine Ahnung, ob es weitere zwei Tage oder zwei Jahre braucht, um die ausstehenden Fehler zu beheben. Agile beseitigt dieses Risiko vollständig. Wenn ein agiles Projekt überläuft, können Sie dennoch eine funktionierende Version liefern, die:

A) Dem Kunden wird durch die Demo bewiesen, dass Sie tatsächlich fast da sind ("Alle diese Geschichten sind fertig, wir können die letzten machen, wenn Sie wollen") und etwas mehr Zeit wird genau das bekommen, was sie wollen.

B) Potenziell ist es gut genug, dass sie trotzdem glücklich sind und freigeben.

Die Beseitigung dieses Risikos eines vollständigen Ausfalls ist für mich schon Grund genug für ein Unternehmen, zu einem agilen Entwicklungsprozess überzugehen. Die Fähigkeit, bessere Software als ursprünglich geplant zu entwickeln, ist das i-Tüpfelchen. Wie bereits in anderen Antworten erwähnt, sind diese „konkreten“ Anforderungen oft noch erstaunlich formbar.

— SpoonerNZ
quelle

Ich verstehe nicht, auf welche Weise A) das Problem löst, das Sie zu Beginn Ihrer Antwort angesprochen haben: Woher wissen Sie, ob die letzten paar Geschichten ein paar Tage oder zwei Jahre dauern werden? Sie wissen nur wirklich, wann Sie sie tatsächlich machen, nicht wahr?

— Giorgio

1

Sie haben Recht, aber der Unterschied besteht darin, dass Sie ein neues Produkt im aktuellen Zustand haben, anstatt ein zu 90% fertiggestelltes fehlerhaftes Stück Software, das nicht veröffentlicht werden kann. Sie haben auch empirische Belege dafür, wie lange es gedauert hat, die freizugebenden Funktionen bereitzustellen, und Ihre Schätzungen der verbleibenden Arbeit, die wahrscheinlich mehr Sicherheit bieten, als kein Beweis dafür, dass etwas, was Sie getan haben, tatsächlich funktioniert.

— SpoonerNZ

Es kommt darauf an: Wenn alle geplanten Funktionen wesentlich sind, ist ein Produkt mit 90% Funktionen unbrauchbar / nicht freigebbar: Es kann nur verwendet werden, um eine Demo dessen zu geben, was bereits vorhanden ist. Meiner Erfahrung nach ist Agilität nicht in allen Situationen vorzuziehen: Es gibt Projekte, für die Agilität besser geeignet ist (sich ändernde Anforderungen, kleine, eigenständige und unabhängige Funktionen), und Projekte, für die dies nicht der Fall ist (stabile Anforderungen, komplex und / oder geschäftskritisch) Eigenschaften).

— Giorgio

Ich stimme zu - in beiden Fällen ist eine zu geringe Leistung nicht gut, aber als Stakeholder würden Sie dem Team vertrauen, das eine voll funktionsfähige Version Ihrer Software erstellt, um damit zu spielen, wo alles funktioniert, aber einige Funktionen fehlen, oder dem Team, das Ihnen eine bietet Haufen von Quellcode, der theoretisch alle Ihre Funktionen enthält, aber viele Abstürze und viele unerwartete Verhaltensweisen aufweist? Ich weiß, wem ich mehr vertrauen würde.

— SpoonerNZ

Natürlich würde ich dem ersten Team vertrauen, aber ich stimme nicht zu, dass man bei einer nicht agilen Methode immer "einen fehlerbehafteten Haufen Quellcode findet, der theoretisch alle Ihre Funktionen enthält, aber viele Abstürze und viele unerwartete Verhaltensweisen aufweist". . Zumindest war dies bisher nicht meine Erfahrung.

— Giorgio

3

Agile ist ideal, wenn Sie eine häufige Rückkopplungsschleife mit dem Kunden benötigen. Dies kann daran liegen, dass sich die Anforderungen häufig ändern, aber auch aus anderen Gründen.

Auf der anderen Seite kann Agile genauso gut funktionieren, wenn die Anforderungen vollständig stabil sind und der Kunde nur eine einzige Big-Bang-Lieferung erwartet. Möglicherweise müssen Sie jedoch einige Anpassungen vornehmen, um das Ausmaß an Engagement zu berücksichtigen, das der Kunde während des Vorgangs erwartet Projekt. Dies bedeutet, dass die Rolle des Product Owners in Ihrer eigenen Organisation ausgefüllt werden muss und diese Person über genügend Mandate des Kunden verfügen muss, um Entscheidungen treffen zu können.

— Bart van Ingen Schenau
quelle

1

Ich frage mich oft, ob Kunden, die nicht zu sehr involviert sein möchten, ein echtes Geschäftsbedürfnis haben. Ich habe dies oft in Projekten gesehen, in denen eine vorhandene Anwendung in eine neue Technologie 'übersetzt' wurde. Sie können den Code überprüfen, wenn Sie Fragen haben, die Ihnen mitgeteilt werden. Niemand wartet auf das Remake.

— Benutzer99561

@ user99561: du hast recht, aber in solchen situationen sind die anforderungen meist nicht vage, sie sind kristallklar - solange sich das neue programm genauso verhält wie das alte. In einer solchen Situation ist ein "agiler" Ansatz in der Tat nicht erforderlich. Ein iterativer, auf Meilensteinen basierender Ansatz (ohne viel Kundeninteraktion) wird in der Tat ausreichen.

— Doc Brown

Kristallklar? Viel Glück beim Herausfinden des genauen Verhaltens und der Ausnahmen. Meistens verstehen sogar die Geschäftsleute nicht, was in der Anwendung passiert. Mein Rat: Lauf so schnell du kannst von diesen Projekten weg. Denn Sie wissen, wann das Projekt startet, aber Sie wissen nicht, wann der letzte Fehler aufgetreten ist, weil sich die Anwendungen anders verhalten. Dieser Fehler wird behoben.

— Benutzer99561

0

Sie können das große Release jederzeit in kleinere Releases (Sprints) aufteilen und Ihren Kunden um Feedback bitten. Auf diese Weise sind Sie sicher, dass Sie das Richtige tun und der Kunde Ihren Fortschritt verfolgen kann.

Wenn etwas nicht stimmt, können Sie Ihrem Kunden die Möglichkeit bieten, Sie früher zu korrigieren, was sehr gut ist. Es ist besser, Ihre Fehler so schnell wie möglich zu korrigieren, als ihm am Ende einen Blödsinn zu zeigen und zu versuchen, ihn zu beheben, wenn Sie nicht einmal wissen, wo Sie anfangen sollen.

— Silviu Burcea
quelle

Ich habe gerade eine Änderung hinzugefügt, um dies zu verdeutlichen. Die Kunden zeigten ein Problem mit genügend Details und einer übersichtlichen Wunschliste und möchten nicht weiter beunruhigt werden. Nehmen wir also an, dass Sie bis zum Ende des Tests kein Kundenfeedback erhalten, wenn Sie einen funktionierenden Prototypen testen können.

— InformedA