Rational Team Concertのある生活～チーム・メンバーの1日
2. 開発が始まる
2.1. 【デイリー・スクラム】（朝会）
今までのデイリー・スクラムは、「付箋（ふせん）」を壁に貼（は）って作った「タスク看板」やホワイトボードなどを使って進めていました。こうしたミーティングも、RTCを使うことで、情報伝達漏れなど減らすことができます。実際の例を、簡単なストーリに沿って紹介します。
- ＜メンバーA＞
- 『昨日からスプリントが始まった、昨日チャットで知らされた計画にバックログがワークアイテムとして登録されていた。担当決めはしてなかったみたいだけど…………』
RTCには、プロジェクトごとに「プロセス」が定義されていることを前回説明しました。それらは、基になる「プロセステンプレート」から選択されますが、ここでは、お勧めのプロセスとして「スクラム」プロセスを例に説明します。この「スクラム」プロセスにおいては、「プロジェクトバックログ」は、ワークアイテムの属性として「ストーリータイプ」を使用します。
- ＜メンバーA＞
- 『【デイリー・スクラム】の前に自分のタスクの状況を確認しておこう。RTCのどこを見たら良かったかな？…そう、「マイ・ワーク」ビューだ』
RTCを使い慣れてくると、RTCに備わっている、以下の2つの異なるビュー（視点）が、重要になります。
- マイ・ワーク
- 自分に割り当てられたワークアイテムを表示します。さらに表示設定で、それらを選択表示することが簡単にできます
- チーム・セントラル
- さらに表示設定で、それらを選択表示することが簡単に出来ます
それぞれ、使いこなすと便利なものですが、ここでは、自分のワークアイテムの選別をするための「マイ・ワーク」ビューについて説明します。「マイ・ワーク」には、自分に関連するワークアイテムだけが表示されます。表示は、3つの部分に分かれています。
- インボックス
- 新規に追加されたワークアイテムが含まれます。それぞれワークアイテムを新規に割り当てられたならば、「現行作業」か「今後の作業」のいずれかに振り分けます。
- 現行作業
- 現行、自分が従事している作業のワークアイテムが表示されます。
- 今後の作業
- 現行の反復に属さない未完了ワークアイテムなどが表示されます。
|
|
| 図10: 「マイ・ワーク」ビュー概説（クリックで拡大） |
＜メンバーA＞
【デイリー・スクラム】
- ＜メンバーA＞
- 『2人離れたところにいるから、どうやるのかと思ったら、Web会議ね。付箋（ふせん）紙と壁の代わりはRTCのタスクボードか。ワークアイテムを作ってるんだから当然だね』
|
|
| 図11: 計画、タスクボード（クリックで拡大） |
＜メンバーA＞- 『打ち合わせの結果は………担当が決まっていなかった作業（ワークアイテム）のうち1つは僕が引き受けて、僕に割り振られていたワークアイテムの1つは、設計までをAさんにお願いして、その後は僕がやることになった。Aさんの作業をサブスクライブしておこう』
| （1） | （2） |
|
|
|
| 図12: ワークアイテムをフィードし、フィードの通知を設定（クリックで拡大） | |
2.2. ファイルを変更する作業を始める
- ＜メンバーA＞
- 『さあ！いよいよ本当の開発作業開始。まずは、これからはじめる作業を確認』
実際の開発では、作っては試して、試した結果をメンバーとレビューしたり、別のテストデータで試したり、そもそも要件定義書の漏れが無いかを確認したりと、紆余（うよ）曲折があると思いますが、ここでは、RTCに習熟した「開発の流れ」の例として、説明します。
（1）今から行う作業（ワークアイテム）を選ぶ
「マイ・ワーク」ビューから、自分が作業する「ワークアイテム」を選択します。その中に書かれていることを理解して、実際の作業に着手します。
「ワークアイテム」の内容は、数日から1週間以内の作業量にふさわしいように分割されていることが理想です。
RTCの「ワークアイテム」は、階層構造にすることが可能ですし、複数の「ワークアイテム」の依存関係を設定することも可能です。
|
|
| 図13: ワークアイテムの作成と関連付け（クリックで拡大） |
（2）開発する（実装、ビルド、テスト、提出、CI）
「ワークアイテム」に記載された作業すべき内容を理解し、作業見積もりやステータスの更新が済んだら、プログラムの作成・変更やドキュメントの修正といった、実際の作業になります。
| （1） |
|
|
| （2） |
|
|
| 図14: 現在の作業の指定（クリックで拡大） |
RTCは、それらの作業の成果物を管理するだけですので、実際の作業はEclipseの「Javaソース管理」といったペインでの作業になります（説明は省略します）。
作業が一段落したら、個人的に、ビルドや（ユニット）テストなどして確認をします。ビルドは、個人レベルのプライベート・ビルドで、内容を確かめたあとで、チーム・ビルドになります（ビルドについては、後の章を参照ください）。
|
|
| 図15: プライベート・ビルド（クリックで拡大） |
|
|
| 図16: プライベート・ビルドの結果確認（クリックで拡大） |
作業結果に問題がなければ、その成果物は、前の状態との差分（変更セット）ができているはずです。RTCは、これを「保留中の変更」ビューで確認できます。「変更セット」をチームで共有するために、ストリームに向けて「提出」を行います。自分の作業は「提出」でよいですが、ほかのメンバーの作業結果も同様にとストリームに「提出」されていますので、ここでは"着信"に対して「受諾」を行い、自分のリポジトリー・ワークスペースに、それを取り込みます。
| （1）提出 | （2）受諾 |
|
|
|
| 図17: （1）提出と（2）受諾（クリックで拡大） | |
これらの作業を反復して、チームとしての作業目標を仕上げていきます。ここで重要なことが「継続的インテグレーション」です（コラムC1参照）。
【コラムC1】『継続的インテグレーション』（CI:Continuous Integration）について）
このプロセスにより、開発インテグレーションを毎日行うことになり、結果として、インテグレーションにともなう問題が減らせる、と述べている。 |
2.3. ほかのメンバーの作業を待つ
- ＜メンバーA＞
- 『海外勤務中のAさんのデータベース設計が終わったら、次の作業なんだけど、まだかな。いるみたいだから、チャットしてみるか、と思ったらアラートだ！』
| （1） |
|
|
| （2） |
|
|
| 図19: フィードしたワークアイ操作のアラート、チームセントラル。フィードの確認（クリックで拡大） |
Aさんの作業をサブスクライブ（図12で設定したフィード）したことによって、ワークアイテムの作業を終了とした時に、イベントとして記録されると同時に、アラートが上がりました。
- ＜メンバーA＞
- 『Aさんの設計が終わった。さて、次の仕事にとりかかるか』
