17

今日、大学でスクラム演習 (ソフトウェア ソリューションを作成するプロセス全体をシミュレートする) があり、よく理解できない問題を思いつきました。

ストーリーを定義し、適切な優先順位を付けたとしましょう。そして、優先度がほとんどないストーリーがあります...おそらく、最後のスプリントで行われるでしょう。

問題は、このストーリーがソリューションの設計に大きなアーキテクチャの変更をもたらした場合はどうなるかということです。たとえば、スタンドアロン アプリケーションの場合、この話だけのために、クライアント サーバー アーキテクチャを使用する必要があります。

私の見解では、どのストーリーが確実に(ある特定の時点で)行われるか、どのストーリーが行われることが重要であるが、いつ重要ではないかを何らかの方法でマークするのは自然ではないでしょうか。それらを念頭に置いて、彼のソリューションを設計するより良い決定を下します。または、この問題にどのように対処していますか?問題がある場合。

前もって感謝します!そして、私のおそらく不自由な質問を許してください。

4

6 に答える 6

9

$$$ がかかっている現実の世界では、優先度の低いものはおそらく決して実行されません。そして、現実の世界ではさらに多くの $$$ が危険にさらされ、優先度が低いことを意味する高いリスク要因がある場合、確実に完了することはありません。あなたの場合、それが確実に行われることがわかっている場合は、デザインセッションで、現在のストーリーで可能な限り少ない労力で、デザインが必要な変更に簡単に対応できることを確認してください.

于 2010-02-13T21:48:12.267 に答える
7

あなたが言ったので:

おそらく、最後のスプリントで行われます。

私はファジーロリポップに同意する傾向があります(そして私から+1)。

ただし、やらなければならないことがわかっているのに、それが最後に配置されている場合、それがアーキテクチャに大きな影響を与える可能性がある場合、それは単に間違った場所にあります。

タスクを分析と実装に分割し、(影響) 分析を非常に早い段階で行って、アーキテクチャに実際に影響があるかどうかを判断し、分析の結果に応じて実装を適切にスケジュールすることができます。

于 2010-02-13T21:52:22.350 に答える
6

問題は、この話が私たちのソリューションに大きなアーキテクチャの変更をもたらしたらどうなるかということです。たとえば、スタンドアロン アプリケーションから、クライアント サーバー アーキテクチャに移行する必要があるのは、この話だけだからです。

あなたの例は現実的ではないと思います。そのような機能は、何らかの形で製品ビジョンの一部でなければなりません。重要度の低い最後のストーリーでそのような変更を発見することはできません。最後のスプリントの前のある時点で考慮に入れる必要があります。そして最終話。つまり、@fuzzy と @Eric に同意します。

  • ストーリーが重要ではなく、リスクがある場合は、実装されない可能性が非常に高くなります。
  • ストーリーが重要でリスクが高い場合は、優先度がそれほど低くない(つまり、優先度が間違っている) 可能性が非常に高くなります。
于 2010-02-14T04:25:58.197 に答える
4

これは、Last Responsible Momentに関する質問のようです。

関係者全員がこれが要件であり、アーキテクチャに影響を与えることに前向きである場合、それを最後のスプリントに入れるのは賢明ではありません。

より可能性の高いケースは、それ必要になる可能性があるということです。早い段階でそれに対応するように設計を調整すると、追加されない可能性がある機能をサポートするために、複数のスプリントを通じてその複雑さが維持されます。(ビジネス要件は変化します。)

柔軟で分離された設計 ( TDDによって進化したものなど) を使用すると、時間の経過に伴う変更のコストを比較的一定に保つことができます。

于 2010-02-13T22:02:57.717 に答える
3

実行する必要があり、大規模なアーキテクチャの変更が必要な場合は、優先度を低くするべきではありません。

優先度の低いものとして分類する必要があると私が確認できる唯一の場合は、それを完全に削除することが許容されるか、将来さらに多くの費用がかかるとしても延期することが許容される場合です (たとえば、製品が完了してドアの外に出て、後でそれのためのより多くの資金が得られるようにします)

于 2010-02-13T21:50:34.503 に答える
2

優先順位は主に顧客の希望によるものですが、完全にそうであるとは限りません。チームが以前に実行する必要があると判断した項目である技術的な側面がいくつかある場合があります。たとえば、ORM の選択は、顧客にとってはほとんど意味がないかもしれませんが、チームの観点からは重要な設計上の決定になる可能性があります。

国際化などに早期に対処する必要がある CMS を含む現在のプロジェクトで、これらのことが数回発生しましたが、一部を処理するために別の会社のソフトウェアを導入するなど、後で変更があったため、これは必ずしも賢明な動きではありませんでした。一部のコードに影響を与える可能性のある翻訳の。

編集:技術的負債クアドラントは、最終的に負債の大きな打撃を受けることが意図的に行われた場合に、これらの種類のリスクを調べて、何に陥るかを確認するのにも役立つ場合があります。

于 2010-02-17T18:20:45.600 に答える