Agiles Szenario, welches ist richtig?

Stellen Sie sich vor Sie User Story 1 haben, die die Durchführung eines Verfahrens erfordert:Agiles Szenario, welches ist richtig?

public static void MyMethod(string paramA);

Mehrere Klassen werden mit dieser Methode, und MyMethod tut alles, um zu vollenden Benutzergeschichte 1, aber nichts mehr.

Sie sind ziemlich sicher, dass in einer zukünftigen Iteration eine andere Geschichte (User Story 2) kommen, entlang welcher das Verfahren benötigen werden:

public static void MyMethod(string paramA, int paramB);

Die bisherigen Anrufe MyMethod wird Refactoring werden müssen, und Einige neue Aufrufe von MyMethod müssen hinzugefügt werden, um die Anforderungen von User Story 2 zu erfüllen (Anmerkung nach Story 2 macht es keinen Sinn, MyMethod nur mit paraMa aufzurufen).

Wenn diese User Story Arbeits 1 ist agiles Denken:

1) implementieren Nur: public void MyMethod (string parama);

2) Implementieren: public void MyMethod (Zeichenfolge paraMA, int paramB); - Aber nichts mit dem zweiten Parameter für jetzt tun. Die Aufrufe geben an diesem Punkt den Wert 0 an den zweiten Parameter weiter.

3) Implementieren: public void MyMethod (Zeichenfolge paraMa, int paramB); - Aber nichts mit dem zweiten Parameter für jetzt tun. Aufrufe geben den korrekten Wert ein (gemäß der Erwartung von User Story 2)

4) Implementieren: public void MyMethod (Zeichenfolge paraMa, int paramB); - Und alle Anrufe Vollständig, um Benutzergeschichte 1 und 2 zu bedecken

Quelle

2009-07-15 Ben Breen

An einem Ende des Spektrums sind die Agile Puristen, die darauf bestehen, dass alles durch Refactoring später durchgeführt werden kann. Auf der anderen Seite sind die Old-School-Big-Design-Up-Front-Crowd, die denken, dass Sie zuerst eine komplette Architektur erstellen und dann Features auf Snap-on-Features. Deine Frage ist perfekt, weil sie die Fehler beider Philosophien aufdeckt, wenn du ihre Prozesse gedankenlos verfolgst. Was Sie wollen, ist maximale Effizienz. Sie müssen also analysieren, was Story 1 und Story 2 in Ihrer Situation sind. Ist Ihre Software ohne S2 lieferbar oder haben Sie die Storys einfach aufgeteilt, um sie zu schätzen und zu planen? Wenn S1 "Add to shopping cart" ist und S2 "Check-out" ist, ist es albern, die Schnittstelle zur Unterstützung von S2 nicht zu erstellen, da Ihre Software ohne sie wertlos ist. In jedem Projekt gibt es eine Reihe bekannter "Have-to-have" -Features, die Ihre Software sogar wert sind, versendet zu werden. Wenn Ihre beiden Geschichten von diesem Set stammen, dann würde ich sagen, bauen Sie die Schnittstelle, um beide jetzt zu unterstützen und verschwenden Sie keine Zeit Refactoring später (# 3).

Normalerweise, wenn S1 und S2 beide im Must-Have-Set sind, sind sie im Backlog dicht beieinander. Wenn dies nicht der Fall ist, dann haben Sie entweder eine riesige Menge von Must-Haves und Ihr Projekt wird nicht so viel Vorteil mit Agile-Techniken gewinnen oder S2 ist wirklich kein Muss. Wenn Sie also einen großen Zeitaufwand (Monate?) Erwarten, um zwischen der Verpflichtung zu S1 und S2 zu wechseln, dann würde ich mit der 1-Parameter-Schnittstelle gehen. Die Zeit ist immer ein großer Beitrag zur Unsicherheit.

Quelle

2009-07-15 23:44:12 DancesWithBamboo

Ich mag es, wenn du viel antwortest. Das einzige, was ich sagen würde ist, dass S1 in der Interaktion 1 und S2 in der Iteration 2 ist. Ich glaube, man sollte immer ein lieferbares Produkt am Ende jeder Iteration haben. Jetzt: Nach einer Iteration ist es unwahrscheinlich, dass das Geschäft glücklich wäre, die Prouds zu versenden, aber es könnte sicherlich zur QA gehen und gut getestet werden.Also streben Sie nach Effizienz und tun dies jetzt (aber es besteht eine geringe Chance, dass Sie es falsch verstehen, wenn sich die Anforderungen und/oder das Design ändern) oder nur das tun, was für Iteration 1 erforderlich ist? –

Beachte auch, dass ich nicht glaube, etwas falsch für die Iteration 1 zu machen. Es hat keinen Sinn, etwas umzusetzen, das komplett neu gestaltet werden muss, wenn Geschichte 2 kommt. Wenn du weißt, was kommt, wäre das verrückt. Aber solltest du die Extra-Meile in S1 gehen, damit du minimale Arbeit machst, wenn die S2 kommt? Oder bevorzugen Sie Fokus, auch wissend: "Vorhersage ist sehr schwierig, besonders in der Zukunft." - Niels Bohr (dänischer Physiker). –

Ich würde nicht in Erwägung ziehen, einen Parameter zu einer Methode hinzuzufügen, die nicht in S1 verwendet wurde, um ein nicht versandbares Produkt zu erstellen. Man könnte es unnötig aufgebläht nennen, aber sicher immer noch funktional. Lieferbar bedeutet nur Fertig gemacht; getestet, dokumentiert, baubar und installierbar. – DancesWithBamboo

Mit einem modernen Entwicklungswerkzeug, Refactoring der Methode, um einen zweiten Parameter zu haben, ist sehr kostengünstig. Die Umsetzung der ersten Geschichte scheint also am sinnvollsten zu sein und dann die Methode neu zu betrachten, wenn es um die spätere Geschichte geht.

Allerdings ... Wie alle guten Fragen ist die Antwort wirklich "es kommt darauf an". In mancher Hinsicht ist Ihr Beispiel zu trivial, um der Diskussion gerecht zu werden. Was wäre, wenn Geschichte A "Kundenname aktualisieren" wäre und Geschichte B eine Art Transaktionseigenschaft hinzugefügt hätte (vielleicht ist paramB der TX-Kontext). In diesem Fall brauchen deine Geschichten vielleicht etwas Arbeit. Macht A ohne B wirklich Sinn? Wird A heute Morgen und B heute Nachmittag implementiert, oder arbeitet B für den nächsten Monat?

Quelle

2009-07-15 16:24:41

Oder ist B ein optionaler Parameter mit möglicherweise einem Standardwert. – amischiefr

Ja, ich verstehe nicht, warum es keine Option ist. Es ist ein perfektes Beispiel dafür, warum Standardparameter am Ende von Funktionen für eine wirkungslose Erweiterung angezeigt werden. Nicht zu beißen ein Java/C# vs C++ Argument darüber :) –

Es ist definitiv kein optionaler Parameter in diesem Szenario. Es ist zwingend notwendig, dass dieser Wert abgerufen und richtig gesetzt wird, um User Story 2 zu treffen. Auch wollen Sie nicht, dass dies eine Diskussion über Sprachgebrauch, mehr High-Level Agile Denken ist, aber ich nehme Ihre Punkte. –

Die Puristen sagen Option 1, aber ich würde auf den gesunden Menschenverstand hören und wenn Sie absolut 100% davon überzeugt sind, dass dies eine Voraussetzung ist, dann würde ich dies in Ihr Design einbeziehen.

Aber Agile basiert auch stark auf Refactoring. Solange Sie diese Schnittstelle nicht öffentlich freigeben, würde ich tatsächlich mit Option 1 gehen, wenn sich dies nicht auf mein Design auswirkt.

Quelle

2009-07-15 16:26:15 Duncan

Also in dem Fall, wo dies eine öffentliche API war, die nicht geändert werden sollte, dann würde es Sinn machen für Story 2 (oder 3, 4 ...) zu implementieren? –

Ja, persönlich würde ich das tun. Eine öffentliche API zu aktualisieren, sobald sie veröffentlicht wurde, wäre eine Welt der Schmerzen. Natürlich müssen Sie sich fragen, WARUM Sie die API an die Öffentlichkeit freigeben würden, vorausgesetzt, dass sie sich noch ändern würde ... – Duncan

Just do 1.

Refactoring einfach ist, ist die Vorhersage der Zukunft nicht.

Das Projekt kann in Dosen sein, neue wichtigere Geschichten können erscheinen, das bedeutet, dass Geschichte 2 nie gebraucht wird, bis du zu Geschichte 2 kommst, kannst du das Problem besser verstehen und alles umstrukturieren. Es gibt endlose Gründe, warum du es vielleicht nicht brauchst.

Quelle

2009-07-15 17:03:22 Pablojim

+1 für den YAGNI-Ansatz – Jacob

+1. YAGNI. Dies ist ein extremes Beispiel, aber das Prinzip ist genau richtig. Was wäre, wenn es zehn Methoden gäbe, die vielleicht in Story 2 umstrukturiert werden müssten? –

"Es kommt darauf an." Wie Sie antworten, hängt weitgehend davon ab, wie diszipliniert Ihr Team ist.

Die Situation, die Sie beschreiben, lädt einen sehr kleinen Schritt auf der anderen Seite in Richtung eines rutschigen Abhangs ein, der zu Code Bloat führt. Der Schritt ist so klein, dass Sie die Steigung nicht bemerken. Ist es sicher? Wahrscheinlich, weil es ein triviales Beispiel ist. Viele "macht es keinen Sinn weiter zu gehen und ..." Fälle sind größer. Und je größer der Schritt, insbesondere wenn er eine Sprint-Grenze überschreitet, desto größer ist die Wahrscheinlichkeit, dass Sie falsch raten und am Ende mit verschwendeter Arbeit und zusätzlichem, ungenutztem Code enden. In einem System mit viel totem oder unbenutztem Code zu arbeiten, ist schlecht.

Wenn Ihr Team, das ein Problem mit Code hat, würde ich für eine Weile "den Antizipationsknopf auf Null stellen", bis die Leute ein Gefühl dafür haben, wie es ist, ein System in kleinen Stücken ohne vorausschauendes Design zu bauen . Ein System zu entwickeln, das sich sauber entwickelt, ist etwas, was viele Entwickler noch nie gesehen haben. Dann besuche die Entscheidung noch einmal. Das produktivste Team, mit dem ich gearbeitet habe, hat den Drehknopf auf Null gestellt und jahrelang so gehalten.

Quelle

2009-07-17 00:36:50

Agiles Szenario, welches ist richtig?

Antwort

Verwandte Themen