アジャイルシナリオ、これは正しいですか？

Question

は、あなたがメソッドの実装を必要とするユーザーストーリー1持っている想像してみて：

public static void MyMethod(string paramA); 

いくつかのクラスをこのメソッドを使用して、そしてMyMethodは、ユーザーストーリー1が、より多くの何を完了するために必要なすべてを行います。

あなたはまた別の話（ユーザーストーリー2）反復将来的になるための方法が必要になります、それに沿って来ることをかなり確信している：MyMethodはへ

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

以前の呼び出しにリファクタリングする必要がありますし、 MyMethodはにはいくつかの新しいコールは、ユーザストーリー2の要件を満たすために追加する必要があります（それが唯一のparamAでMyMethodはを呼び出すことは理にかなっていたことがない物語2の後に注意してください）。

ユーザーストーリー1について作業するにアジャイルの考え方です：のみ実装

1）します。public void MyMethodは（文字列paramAを）。

2）を実装します。public void MyMethodは（文字列paramA、int型のparamBを）。 - しかし、今は2番目のパラメータで何もしないでください。この時点で、呼び出しは2番目のパラメータに0を渡します。

3）を実装します。public void MyMethodは（文字列paramA、int型のparamBを）。 - しかし、今は2番目のパラメータで何もしないでください。コールは正しい値で渡されます（ユーザストーリー2の期待通り）

4）実装：public void MyMethod（string paramA、int paramB）; - そしてすべての呼び出しは完全にユーザーストーリー1と2をカバーするため

Answer 1

スペクトルの一端には、後でリファクタリングすることですべてを達成できると主張するアジャイルの純粋主義者があります。もう一方の端には、あなたが完全なアーキテクチャを最初に構築し、その上に機能をスナップする必要があると考える古いデザインのBig-Design-Up-Frontの群集があります。あなたの質問は完璧なものです。なぜなら、プロセスを気にせずに実行すれば、両方の哲学の失敗を露呈するからです。あなたが望むのは最大の効率です。だから、ストーリー1とストーリー2があなたの状況にあるものを分析する必要があります。あなたのソフトウェアはS2なしで出荷可能ですか、見積もりや計画に役立てるためにストーリーを分割しましたか？ S1が「ショッピングカートに追加」であり、S2が「チェックアウト」である場合、S2がサポートされていないとソフトウェアを使用することができないため、S2をサポートするためのインターフェイスを構築しないことは愚かです。すべてのプロジェクトには、あなたのソフトウェアを出荷する価値のあるものにするための既知の「Have-to-have」機能があります。あなたのストーリーの両方がそのセットからのものであるなら、私は今や両方をサポートするためにインターフェイスを構築し、後でリファクタリングする時間を無駄にしないと言います（＃3）。

通常、S1とS2の両方が必須設定になっている場合、それらはバックログで一緒に閉じます。これが当てはまらない場合は、膨大な量の必須リソースが必要になります。また、アジャイル技術を使用してもその利点が得られない場合や、S2が本当に必要なものではありません。ですから、S1とS2へのコミットメントの間に大きなチャック（月？）が来ることを期待しているのであれば、私は1つのパラメータインターフェイスに行きます。時間は常に不確実性に大きな貢献をしています。

Answer 2

最新の開発ツールでは、メソッドをリファクタリングして2番目のパラメータを非常に低コストにします。最初のストーリーを実装するのが最も理にかなっていると思われ、その後のストーリーについてはメソッドを再訪するように見えます。

は、しかし...すべての良い質問のように答えは「それが依存」本当にです。いくつかの点であなたの例は議論を正義するのはあまりにも些細なことです。ストーリーAが「更新顧客名」であり、ストーリーBが何らかのトランザクション機能を追加した場合（おそらくparamBはTXコンテキストです）どの場合には、あなたのストーリーが何らかの仕事を必要とするかもしれないAはBなしでは本当に意味がありますか？ Aは今日の朝、Bは今日の午後に実装されているのか、来月はBの仕事ですか？

Answer 3

純粋主義者は、オプション1と言うだろうが、私は常識に、あなたは絶対にこれは、私はあなたのデザインにしてこのことを考慮したい要件であることを100％確信している場合は聞くだろう。

アジャイルはリファクタリングを中心にしているため、このインターフェイスを一般公開していない限り、これを変更してもデザインには影響しません。

Answer 4

ちょうど1

リファクタリングを行い、将来を予測することはないが、簡単です。

プロジェクトは缶詰することができる、新しい、より重要な話はそれが物語2は、あなたがよりよく問題を理解し、すべてをリファクタリングする必要があるかもしれない物語2に到達する時間によって、必要とされることはありません意味表示されることがあります。あなたがそれを必要としないかもしれない無限の理由があります。

Answer 5

「それは依存します。あなたがどのように答えるかは、あなたのチームがどのように訓練されているかによって大きく異なります。

このような状況では、滑らかな斜面に向かうラインの向こう側に非常に小さなステップがあり、コードの膨張につながります。このステップは非常に小さく、斜面に気付かない。それは安全ですか？おそらく、それは簡単な例ですから。多くの人が「進んでいくのは理にかなっていない」というケースはもっと大きい。また、ステップが大きくなると、特にスプリントの境界を横切る場合は、間違っていると思われる可能性が高くなり、無駄な作業と余分な未使用コードが発生します。デッドまたは未使用のコードをたくさん使っているシステムで作業する。

コードが肥大化しているチームでは、予期しないデザインの小さな部品でシステムを構築するような気持ちが出てくるまで、「予測ノブをゼロに設定する」と思います。システムがきれいに進化するのは、多くの開発者が一度も見たことのないものです。その後、決定を再確認します。私が働いた最も生産的なチームは、ゼロに設定されたノブを放置し、何年もそのように保ちました。