スクラムでは、ユーザー ストーリーの原則があり、これらのステミング タスクなどが最終製品まで繰り返されます。これは問題ありません。
しかし、実装が必要な機能が 100 個あるとしましょう。現実の世界では、通常の補助的な作業の多くが完了するまで、これらの機能に開発者を配置することはできません。このための機能の全体的なアイデア?)、または必ずしも機能として現れるとは限らない基礎となるものを構築します。
それで、これはどこで起こりますか？
5 に答える
9
私の理解では、スクラムでは、各ユーザー ストーリーを実装するために必要なものだけを構築します。したがって、作業中のユーザー ストーリーの機能を実装する必要がある場合にのみ、機能ではない基本的なものを構築します。
于 2009-03-16T17:29:01.143 に答える
9
私の見解では、非機能的なタスクはまだ製品バックログに入れることができます-私がスクラムを使用していたとき、私たちは確かにそうしました. なぜそれらを重要視すべきなのかを製品所有者に説明しなければなりませんでした。プロダクト所有者がそれらが非常に重要であると信じていない場合、それらは完了しません。所有者は結果を受け入れなければなりません。負荷テストなどのリクエストを却下して何度か噛まれた後、失敗する可能性があります:)
一方で、本来は重要であると信じていた機能以外の要件がいくつかあることに気付くかもしれませんが、影響を与えずに衰退する可能性があります。開発者の本能が間違っていることもあります:)
真にゲーティング要因であるタスクについては、製品所有者に正直に言って、それらを実行する必要があると主張する必要があると思います. プロジェクトを継続するために必要な程度にプロダクト オーナーと仲良くできない場合は、UI デザインを取得できないことよりも大きな問題があります :)
于 2009-03-16T17:32:36.673 に答える
4
補助的なタスクを、それを必要とする最初の機能に組み込みます。
製品バックログとスプリントバックログの違いを区別することが重要です。製品バックログには、「方法」ではなく「何/理由」を表すユーザーストーリーが含まれています。ストーリーがスプリント用に選択されると、ストーリーはそれを構築するために必要なタスクに分割されます。例：「UIデザイン」は、「購入するアイテムの選択」ストーリーのタスクになります。タスクに依存関係がある場合でも、スプリント計画レベルで害はありません。実際、ほとんどの場合、他の製品のバックログアイテムの作業を楽にするタスクがあります。
お役に立てば幸いです。
于 2009-03-27T03:41:17.533 に答える
3
基本的に、それは各機能内で発生します。これは、言うは易く行うは難しですが、おそらくアジャイル インクリメンタル ソフトウェア開発の要点です。
たとえば、多くの「機能として現れるとは限らない基本的なもの」を構築する代わりに、それは必要ないと考えて、問題の機能に必要なだけ構築する必要があります。
于 2009-03-16T17:30:18.800 に答える
0
私の意見では、可能な限り多くのことを「ストーリー」として含めるのが最善であり、時間が適用されているものを誰もがよく見ることができます.
ただし、実行しなければならない予定外のタスクが常に存在します (たとえば、マシンが壊れた場合の再インストールなど)。そのタスクの 1 つのオプションは、反復ごとに 300 ストーリー ポイントのベロシティがある場合、各反復で数パーセントの自由時間を残すことです。次の反復では、過去の履歴に従ってこれらの値を調整できます。
于 2009-03-16T17:29:40.517 に答える