PR

Rational Team Concertのある生活~チーム・メンバーの1日

2010年11月30日(火)
渡邉 雄一宮城 豊

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)について)

図18: 継続的インテグレーション(クリックで拡大)


Martin Fowler, Matthew Foemmelによる造語。彼らは、以下の4つの要素を満たして、テスト部分も含めて「すべてが自動化された」「再現可能な」ビルドを、「日に何度も」実施する活動、と定義している。

  1. すべてのソースコードが格納され、誰でも必要なそれを抽出することが可能な唯一の口を作る
  2. ビルド・プロセスを自動化して、誰でも、コマンド1つでソースからシステムを作れるようにする
  3. テスト作業を自動化して、コマンド1つで、いつでもテスト・スイートを実行できるようにする
  4. 現行の実行可能モジュールで、もっとも適切であると自信を持てるものを、誰でも入手可能にする

このプロセスにより、開発インテグレーションを毎日行うことになり、結果として、インテグレーションにともなう問題が減らせる、と述べている。

2.3. ほかのメンバーの作業を待つ

<メンバーA>
『海外勤務中のAさんのデータベース設計が終わったら、次の作業なんだけど、まだかな。いるみたいだから、チャットしてみるか、と思ったらアラートだ!』
(1)

(2)

図19: フィードしたワークアイ操作のアラート、チームセントラル。フィードの確認(クリックで拡大)


Aさんの作業をサブスクライブ(図12で設定したフィード)したことによって、ワークアイテムの作業を終了とした時に、イベントとして記録されると同時に、アラートが上がりました。

<メンバーA>
『Aさんの設計が終わった。さて、次の仕事にとりかかるか』
株式会社SRA

産業開発統括本部 製造・組込システム部 コンサルティンググループに所属。
RDBアプリ開発、プリンタドライバ開発、ネットワーク設計・管理(動的経路制御)などを経て、近年は、ツールの導入・活用のコンサルテーションに従事している。最近の担当分野は、「構成管理」、「脆弱性診断」、「プロジェクト管理」など。仕事上の最近の興味は「組織プロセスとツール活用の効率化・最適解」。

株式会社SRA

産業開発統括本部 製造・組込システム部 コンサルティンググループに所属。
1982年SRA関連会社より1986年SRAに。約10年間業務アプリ・エミュレータ等の開発に従事、以降現在まで、ツール導入・活用のコンサルテーション業務に従事する。Rational 製品のPurifyとは17年来の付き合い。最近メタボ体策で、知らない町をぶらぶら散歩し、道に迷う事に喜びを覚えている。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています