CodeZine(コードジン)

特集ページ一覧

Eclipseの開発手法を受け継いだ
分散アジャイル開発のためのプラクティス

「Eclipse-Way:分散アジャイル開発のためのプラクティスとその事例」セッションレポート

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2009/02/27 15:00

目次

「Team First」と「ワークアイテム」の考え方

 Team Concertの開発やツールの機能としての基本的なポリシーの一つに「Team First」の考え方がある。チームが基本的な発想の軸になっていて、ドキュメントを書くチームやコードを書くチームなど独自のプロセス、作業領域を持つチームが複数同時進行し、場合によってはお互いのチームをフォローしていく。また、チームは「イベント」を生成し、自分たちが現在何をしているかという状況把握を行う。あくまで個人の観点ではなく、チームとしてイベントをクリアして成果物を作り上げていくことがアジャイルの特徴だ。

チームが発想の軸となる考え方「Team First」

 また、トラッキングを強く意識していることもアジャイルの特徴。「作業依頼のチケットを発行して、それをトラッキングしていく」というスタイルは、広く知られるようになったが、Team Concertが採用するJazzの世界観では、「ワークアイテム」を軸に考える。ワークアイテムと「チェンジセット」は、ソースコードや設定ファイルなどのリソースの変更として密にリンクされている。ほかにも、チームはリリースのためにビルドを作ったり、その都度スナップショットを撮っていく。このように、ワークアイテムを軸にインフォメーションモデルを規定していくことで、誰がいつ何をするのかを関連づけ、管理することができる。

ワークアイテムで、誰がいつ何をやるのかを管理する

実際のRational Team Concertの開発体制

 実践例としてRational Team Concertの開発をみていくと、まず「分散開発体制」を採用していることが挙げられる。この地図のように開発チームは世界8箇所に拠点がある。メンバー数は時期によって異なるが、通常は70名前後、リリースが近くなると100名くらいになり、この体制で3年間続けている。

世界8拠点に散らばった分散開発体制

 作業のタイムラインは、この図のようになっている。これは1回のリリースサイクルを表現したもので、Team Concertでは毎年6月下旬にリリースを公開している。昨年の6月にバージョン1.0を公開しており、今年の6月に2.0をリリースすることが決まっている。最初のフェーズはウォームアップと呼び、前回のリリースに対する反省を踏まえた上で次のリリースに何を盛り込んでいくかというマスタープランを決定する。

1回のリリースサイクルを表したタイムライン

 最後の部分はエンドゲームと呼び、機能の作成は終了しているので、細かいバグを修正し商品としての安定度を高めていくフェーズとなる。このマスタープランとエンドゲームの間を、通常は4週間のスプリントで回していく。100名で4週間のイメージとなる。スプリントごとにマイルストーンを設定し、ダウンロードして使用できるものを提供するまでが4週間ということになる。一つのスプリントは「プラン」「デベロップ」「スタビライズ」で構成されており、イテレーション終了時には外部デモを必ず実施し、レトロスペクティブとnew & noteworthyによって何を達成したかを確認していく。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • 吉澤 亨史(ヨシザワ コウジ)

    元自動車整備士。整備工場やガソリンスタンド所長などを経て、1996年にフリーランスライターとして独立。以後、雑誌やWebを中心に執筆活動を行う。パソコン、周辺機器、ソフトウェア、携帯電話、セキュリティ、エンタープライズ系など幅広い分野に対応。

バックナンバー

連載:developerWorks Liaison

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5