問題タブ [sprint]

スクラムの課題の 1 つは、QA をプロセスに組み込む方法です。確かに、QA はスプリント中に個々のユーザー ストーリーについて開発者と協力しますが、本番環境にリリースする前に、完全に完了したスプリントで完全な回帰テストと負荷テストを行う時間を QA に与えるのはどうでしょうか?

私は2つのアプローチを見てきました：

1. スプリントの最終日に生産を開始します。また
2. スプリントの 1 週間後に生産を開始

どちらのアプローチにも課題があるので、すべてのスプリントをリリースするほとんどのショップは何をしているのでしょうか?

スプリント バックログの作業項目として含めて追跡できるタスクの種類は何ですか?

(ユーザー ストーリーの) 分析、レビュー、および単体テストを含めることはできますか? または、コア コーディング タスクのみを含めてスプリント バックログに追跡することはできますか?

基本的に、私はユーザー ストーリーを技術的なタスクに分割してスプリント バックログを更新しており、コーディング以外の役割を持つタスクをスプリント バックログで更新および追跡できるかどうかを知りたいと考えています。

私はプロダクトオーナーであり、テーマ別のスプリントの設定を手伝っています。明確にするために、テーマとは、すべてのユーザーストーリーが関連しているか、共通の目標の周りに集まっていることを意味します。含めたいテーマでうまくいかないストーリーがまだあります。問題は、私がスプリントのビジョンを断片化すると、私たちもうまく機能しないということです。助言がありますか？

プロジェクトの管理には、TFSでスクラム1.0を使用しています。同時に異なるスプリントに取り組む2つの（まもなく3つになる）チームがあります。スプリントバーンダウンチャートが歪んで完全に不正確になるため、これはTFSに問題を引き起こすようです。

私は両方のチームを同じ反復パス/スプリントの下に移動し、エリアごとに区別しています。しかし、これは理想的ではありません。

私の質問は、他のチームがどのようにスクラム1.0を使用して、同時に複数のスプリントを効果的に実行しているかについてです。少なくとも、各スクラムチームのスプリントバーンダウンとベロシティレポートが必要です。

どうもありがとう、ジョン

最高のスプリントの長さは状況/会社ごとに異なることを私は知っています。そうは言っても、柔軟なスプリントの長さを使用して成功した人はいますか？また、短い（1週間）スプリントと長いスプリントについて強い意見がある人はいないでしょうか。

背景：現在、1週間のスプリントを使用して開発しています。私たちの製品所有者はこれに満足しているようです。ただし、柔軟性を確保するために、特定のプロジェクトではスプリントの長さを長くするように何度か依頼しました。すべての場合において、私たちは短いスプリントに固執します。

私たちはアジャイル開発方法論に従っています。SCRUM マスターとして、Sprint BackLog を維持しています。プロジェクトの途中で特定のタスクの労力が増加した場合に対応するためのベスト プラクティスは何かを知りたいです。

たとえば、私は ABC タスクを実行しており、スプリントの開始時にそれを完了するのに 10 時間かかると見積もっていましたが、2 日目には 20 時間かかることに気付きました。

イテレーション 2 のスクラム計画は、イテレーション 1 のスプリント レビュー (デモ/レトロスペクティブ) の後または前に行われますか?

Team FoundationServer2010をTeamFoundationServer 2012にアップグレードし、優れたTFS2012 Webアクセスを使用して、製品のバックログ、スプリント、およびスクラムボードを処理しています。そして、それはすべて非常にうまく機能します。これを除くすべて：TFS2012 WebアクセスでWORKにアクセスすると、製品バックログが表示されます。ただし、スプリント（過去/現在または将来のスプリント）に割り当てられていないPBIのみが表示されることを期待しています。ただし、ステータスがDoneではないすべてのPBIが表示されます。PBIがスプリントバックログに移動されると、この製品バックログから削除されると思います。右？

作業項目クエリを編集して、反復パスを持つPBIのみがスプリント内にないように変更したいと思います。それをしてもいいですか？

[バックログクエリの作成]ボタンがあり、それをクリックすると新しいクエリが作成されます。そのクエリを編集できますが、バックログ/計画画面のクエリとしては使用されません。

このクエリが新しく作成されたTFS2012チームプロジェクトのクエリに似ているかどうかを確認しようとはしていません。TFS2010チームプロジェクトからのアップグレードと関係があるかもしれません。

前もって感謝します。

10月15日編集：

この質問を作成したとき、PBIがスプリントバックログと製品バックログの両方に含まれる可能性があるのは間違っていると感じました。ただし、計画がどのように行われるかを考えると、これは問題ないかもしれません。製品バックログは、実行されていないPBIのバックログと考える必要があります。PBIは、スプリント（現在または将来、あるいは過去のスプリント）に対して計画される場合がありますが、実行されません。

製品バックログビューの予測機能について：これにはいくつかの問題があります。バックログの優先度は、すでにスプリントに割り当てられたPBIよりも高い優先度を持っています-これは改善される可能性があります。この機能は、将来のスプリントの非常に大まかな見積もりにのみ使用できると思います。スプリントに多くのPBIがある場合、予測機能は誤解を招く可能性さえあります。それが私の意見です。

この一連の質問は、スクラム 2 を使用して TFS 2012 の領域と反復をセットアップする方法に関するベスト プラクティスの回答を引き出すことを試みます。

コンテキスト: 私たちは TFS 2005 から Team System を使用しており、最初に所有する製品ごとにチーム プロジェクトを作成し、次に MSF 4.2 プロセス テンプレートを使用しましたが、最終的に微調整しました (いくつかの作業項目の種類にいくつかのフィールドを追加しただけです)。

現在にロールフォワードすると、現在 TFS 2012 と VS 2012 を実行しています。過去の経験とコミュニティからのフィードバックを考慮して、単一のチーム プロジェクトとスクラム 2.1 に移行し、領域を使用して製品とチームを分離します。次のリンクは、このアプローチをよく読んでいます。

• http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
• TFS 領域、最適な定義と構成
• Team Foundation Server - エリア / イテレーション

エリアに適用する予定の典型的なレイアウトは、次のようなものです。

上記は私たちの環境にとって論理的であるため、概念的には非常に満足しています。上記によると、次のようなチームがあります: * "クライアント A チーム" * "クライアント B チーム"

質問 1)私たちのチームはそれほど大きくなく、管理をより管理しやすくするために、製品ごとにチームを定義したくないと考えました。物理的にクライアントごとにチームがあり、そのクライアントのすべての製品を監督しているためです。これは間違いですか、それともこれでよろしいですか?

質問 2)上記のチーム構成に問題がないと仮定すると、上記の各エリアを各チームに「マッピング」するのは正しいでしょうか。つまり、チーム「クライアント A チーム」の場合、エリア「クライアント A」(およびすべてのサブエリア) を次のように指定します。そのチームが所有する領域。デフォルトのエリアはどうですか? 「クライアント A」エリアのルートをチームのデフォルトとして設定してもよろしいですか?

イテレーションのレイアウトに関しては、次のような類似のものを計画しています。

質問 3)これは、特にバックログを表示する TFS に関しては、反復を正しく行うのが難しいようです。具体的には、TFS スクラム 2 反復のセットアップでは、計画とその後の開発のためのリーフ レベルの反復のみを選択 (チェック ボックス) する必要があるようです。したがって、上記の例を拡張すると、「クライアント A チーム」が次の 4 週間 (2 週間のスプリントを想定) で新しい製品 B の作業を開始できるようになる可能性があります。次に、リリース 1 から「スプリント 1」と「スプリント 2」のみを選択 (チェック ボックス) しますか? 正しく理解/使用していますか?

質問 4)チーム バックログ イテレーションの選択 - これは、製品ごとではなく、クライアントごとにチームを配置するという私たちの概念のために問題になる可能性がありますが、私の理解が間違っているだけかもしれません。TFS エリアのセットアップでは、どの反復が「チームのバックログ反復」であるかを指定します。私の問題は、私たちの PBI (製品バックログ項目) が製品固有のものであり、別の製品の PBI と混合したくないということです。したがって、おそらく「製品 B」ではなく、「チームのバックログ イテレーション」としてエリア「クライアント A」を選択した場合にどのような影響があるかは、まだ理解できません。私はここで自分自身を混乱させていると思います-賢明な選択は何でしょうか?

上記の質問は、定義された各 TFS 2012 チームに対して、イテレーション、エリア、チーム バックログ イテレーション、および既定のエリアのこれらの選択がどのような影響を与えるかを理解していないことに起因します。このセットアップで私が抱えているいくつかの問題は、TFS がチームの製品バックログとスプリント バックログを正しく識別することです。

1 つのチーム プロジェクトと製品の複数の領域 (一般的に推奨されている) が問題を複雑にしているのかどうかはわかりません。

質問 5) TFS Web アクセス Web サイト - 「作業 | 作業項目 | 共有クエリ」の下にある特定のチームについて、「現在のスプリント」(ブロックされたタスク、スプリント バックログなど) というフォルダーの下に定義済みのクエリがありますが、これらのクエリは"Root Project\Release 1\Sprint 1" に対してハードコードされています - これらは、反復に対して定義された日付が与えられた現在のスプリントを自動的に検出するべきではありませんか? そうでない場合、これらのクエリを維持するためのベスト プラクティスは何ですか?

これらの質問に対処するのに役立つ、または Scrum 2 TFS セットアップを成功させるためのガイダンスを提供する、TFS 2012 および Scrum 2 固有の高品質のトレーニング/チュートリアルを知っていますか?

私たちのチームは、スクラムとアジャイル技術を採用する予定です。複数の顧客向けに開発した製品があります。この顧客から必要な要件が提供されたので、アジャイル技術を採用しても問題ありません。

しかし、ある時点 (たとえば、スプリント中) に新しい顧客が現れ、現在のものとは少し異なる製品のデモを入手したいと考えています。これは、いくつかの新機能または動作の小さな違いである可能性があります。そして彼は、たとえば平日にこのデモを取得したいと考えています。私たちの製品がこの機能をサポートしていることを示すことは非常に重要です (そうでなければ、彼は競合他社に対処するため)、その週にこの機能を (部分的に) 開発する必要があります.

この種の機能をアジャイルでどのように処理する必要がありますか? それらを現在のスプリント バックログに移動しますか? それとも、1 つのチームを 2 つに分割して、別のスプリントを作成しますか? それとも別の方法があるのでしょうか？