「サーバーをv1からv2にアップグレードする」、「起動パフォーマンスを向上させる」、「ログインモジュールをリファクタリングしてコードの複雑さを軽減する」などの技術的な項目が製品のバックログに含まれる場合、技術的でない製品所有者がそれらに優先順位を付けるにはどうすればよいですか。対他のより機能的なバックログアイテム？
技術的なもののために別のバックログがあるべきですか？製品のバックログで機能的および技術的なものを優先できる2人の共同POの役割を担う必要がありますか？
4423 次
3 に答える
11
通常、「バニラ」スクラムでは、あなたが言及した技術的なタスクは別々の話にはなりません。
私にとって、非技術系の PO は、「サーバーのアップグレード」などのストーリーを見るべきではありません。ビジネスの話ではなく、エンドユーザーには見えないので、このように定式化すると優先順位付けが難しくなります。仕事のビジネス価値に応じて優先順位を割り当てる必要があります。「アップグレード」はあまり意味がありません。「より多くの同時接続を許可する」、「ダウンタイムを減らす」、または「チームの速度を向上させる」ことでさえ、非技術者にはるかに価値のある洞察を提供する可能性があります. 非技術的な説明が見つからない場合は、アップグレードの必要性について自問自答してください:)
「リファクタリング」の話はさらに複雑です。なぜそれが物語なのか自問しましたか？リファクタリングはストーリーのタスクとして実行できますが、それ自体がストーリーになることはめったにありません。したがって、ログイン機能を改善したい、またはより多くの機能を提供したい場合、それは話ですが、ボンネットの下でいじくり回すことは 1 つとは見なされません。ビジネス目的のないリファクタリングは、いわゆる「金メッキ」に簡単につながる可能性があることにも注意してください。
関連するビジネス ストーリーのタスクである「パフォーマンスの向上」と「リファクタリング」を使用して、「アップグレード」ストーリーをスパイクとして実行することをお勧めします。
PS このトピック (主にパート 3) についての良い議論は、Mike Cohn による「User Stories Applied: For Agile Software Development」という優れた本にあります。
于 2009-09-03T11:01:59.900 に答える
0
デュアルバックログアプローチで成功しました：
プロダクト バックログは、プロダクト オーナーが所有します。これには、チームによって評価され、製品所有者によって優先順位が付けられるストーリー レベルのアイテム (機能) が含まれています。この見積もりプロセスでは、ストーリーを小さなタスクに分割します。
チーム バックログは開発チームが所有します。比較的小さい (スプリント内で完了できる) タスク レベルの項目が含まれています。それらは、たとえば障害としてストーリーにリンクできます。ストーリーを完了するには、次の技術的なタスクを最初に完了する必要があります。それらは独立しているため、ストーリー自体には必要ありませんが、将来の高速化を可能にするために技術的負債を返済します。
(いくつかの大規模なマルチプロジェクト プログラムでは、プログラム管理チームが所有し、優先順位を付けた壮大なレベルのアイテムを含むプログラム バックログがあり、後で製品バックログへのストーリーに分割されました。)
于 2009-09-03T09:35:28.813 に答える