シナリオ3）シナリオ1）において時期によってルールを変える
中規模・大規模でアジャイル開発を行おうとした場合、試行錯誤するようなプロジェクト初期にはルールを緩めて創造性を損なわないようにし、プロジェクト後期の量産期にはメンバーが多くなったり分散チームで行ったりするため、ある程度の縛りをいれる、という運用が求められることがあります。
ここではシナリオ1）のソース管理においてワークアイテムとの関連付けを必須とする、というルールを拡張して、以下のルールをRTCに設定しようと思います。
「スプリント1では誰でも提出できる。ただしワークアイテムの関連付けあるいはコメントのいずれかを指定することとする。スプリント3ではスクラム・マスターとチーム・メンバーだけが提出できる。ただし、ワークアイテムの関連付けとコメントの入力が必須とする」
まず、プロジェクト・エリアのプロセス構成タブで構成セクションの［チーム構成］を開きます。開発ラインの下を開いていくと、プロジェクトで定義した反復構造が同じように見えてきます。
これをよく見ると、シナリオ1）で設定したものと同じ「操作の振る舞い」という設定項目が複数出てきていることに気が付きます。
スプリント1の中にも「操作の振る舞い」の設定がありますし、スプリント3の中にも「操作の振る舞い」の設定があります。
つまり、これらに異なる設定をすることで、スプリント1とスプリント3のルールを変えることができる、というわけです。
また、スプリント1から上をたどると、「リリース1．0」「メイン開発」「チーム構成」の各レベルに「操作の振る舞い」がありますが、これは階層構造として上位で設定したものが下位に伝搬する動作をします。
スプリント1のレベルで許可をはずしたとしても、その上位のどこかで許可がされていたら、それは許可されているとみなしますので注意が必要です。
先のルールを実現するためには、まずシナリオ1）で設定したチーム構成レベルの振る舞いをはずします。設定をはずすには、構成セクションで［チーム構成］-［操作の振る舞い］の構成でスクラム・マスターに対する［ソース管理］-［提出（クライアント）］の欄を選択したうえで、［この操作に前提条件およびフォローアップ・アクションが構成されます］のチェックをはずします。
次にスプリント1の操作の振る舞いをルールに従うようにするため、利用者（デフォルト）役割に対して、前提条件として「ワークアイテムおよびコメントは必須」を追加して、制約セクションで提出時に変更セットに必要なものとして「いずれか」を選択します。
こうすることでRTCは、スプリント1では利用者誰もが提出が可能であり、提出時にはワークアイテムの関連付けか、コメントの入力により提出が可能、という振る舞いをします。
次にスプリント3はスクラム・マスターとチーム・メンバーだけに許可を与えるためには、次の画面のような設定をします。
役割としてスクラム・マスターとチーム・メンバーだけに構成を行い、制約は提出時に変更セットに必要なものとして「両方」を選択しましょう。
これで今がスプリント1なのか、スプリント3なのかによって、RTCの振る舞いが変わることになります。このようにスプリントごとに設定を変えることで、時期に応じたルールの強弱を付けることができ、プロジェクトの状況に応じた柔軟なルール運用が可能となります。
組み込まれたプロセス定義文書を参照する
プロセス・エンアクトメントの実現、つまり開発プロセスを作業環境から離れたところに置いたままにするのではなく作業をしながら開発者がすぐに使える状況にするという観点で、RTCは別の機能として開発プロセス文書をRTCの中に組み込むということができます。
プロジェクトを作成した際に選択した製品のデフォルトのプロセス・テンプレートには、その種類に応じたプロセス文書、すなわちそのプロセスで定義された文書（誰が、何をして、何を作成する、それにかかわる技術文書と共に）が含まれています。
プロジェクト・エリアの「プロセスの記述」セクションからそれを表示することができます。プロセスの記述セクションに、選択したプロセス・テンプレート名がリンクとしてあるので、それをクリックするとそのプロセスのプロセス定義文書がHTMLの形式で表示されます。
スクラムのリンクをクリックすると、このスクラムのプロセス・テンプレートに関する説明文書が表示されます。
このように、開発プロセスの文書がRTCの中に組み込まれることで、開発者が容易に参照したり、調べたりすることができるようになります。より一層プロセスが現場の開発者に使われる状態になるでしょう。
