ひつじのにっき

mhidakaのにっきです。たまに長文、気が向いたとき更新。

【12-A-4】Eclipse-Way :分散アジャイル開発のためのプラクティスとその事例

【12-A-4】Eclipse-Way :分散アジャイル開発のためのプラクティスとその事例 藤井智弘
大規模開発でのアジャイルの問題点と解決について。


ポイントは以下の2つ
- アーキテクチャとチームを密に関係させる
- 分散開発では無駄をやらない+ロスを最小化することを考える

12-A-4 Eclipse-Way :分散アジャイル開発のためのプラクティスとその事例 藤井智弘

アジャイル開発の有効性は認知されつつも、規模の拡大とオフショア等の分散体制の壁にぶつかっています。
Eclipse-WayはEclipse自体の開発から生まれたアジャイルプラクティス集であり、
RationalTeamConcert(RTC)の開発で、100人×3年以上にわたって適用され、
またその過程はインターネット上に公開されています。
本セッションでは、RTCの開発をひとつの例に、アジャイルプラクティスのスケールアップのポイントを探ります。

◆導入
 Rational 反復型開発(RUP)の導入
 -> 社内開発についてはRUPからアジャイルに転換

 アジャイルの課題★
  規模の拡大
  オフショア等、分散体制の壁

 Jazz Project
  オープンソースの開発モデルを実践
  完成前に公開、意見を受け入れてイテレーション(反復)に生かす。

◆Eclipse Way概要
 アジャイルで共通のプラクティスを含む
  継続した統合 :ウィークリービルド等
  ライブデータ:リリースごとのデモ等
  マイルストーンファースト、アプティブプランニング等

 これにオープンソースに特化したプラクティスを追加
  ・コミュニティを巻き込む(不特定多数の意見導入)
  ・New And Noteworthy(新規事項、突発事項を考慮)

 スケールアップのためのプラクティス
  ・APIファースト、コンポーネント中心

◆Team First
 ウォーターフォール:専門性に応じた役割分担
 アジャイル        :役割は流動的。

 チームの役割、状態に応じて状況が変わるはずで、
 すべての考え方はTeamをベースに
 
◆Rational Team Concert開発 実践例
 開発チーム
  8カ所に別れて開発、70人から100人ぐらい。
 
 リリースサイクル:年に1回のリリース
 
 ウォームアップ :マスタープランを作る
 イテレーション :1サイクルは4週間
  → イテレーション終了後には必ずライブデータ(デモ)を実施★
 エンドゲーム   :バグ修正、細かい作り込み

 役割モデル:コンポーネントを意識
  → アーキテクチャとチーム編成は密に関係。
  → チームでコンポーネントに責任を持つ、コンポーネントベースの開発

 分散開発でチームの足をひっぱらないことを重要視
 各々のTeamで独自のプロセス、作業領域を持ち、
 分散しているなかでも小チームのよさを維持する

◆アジャイル化に向けての不安
 イテレーションによってストーリーを積み上げ
  → 最終的に本当に必要なものが出来上がるのか?【不安】★

 ・イタレーションの成果をどうやってハンドリングするのか
 ・全体のプランってどうする?

 好き勝手放題をどう収束するの?
  ウォーターフォールは要求が決まってるはずなのに振れてしまう
  要求定義がさらに曖昧なアジャイルでは尚更収束しないのではないか?

◆要求構造
 テーマとフィーチャー
 要求を段階的に細分化。テーマ:大まかな要求、フィーチャー:さらに機能的な単位で分ける
 リリースプランでは成果をテーマとフィーチャー別に設定、イテレーション時に確認していく。
  (テーマ・フィーチャーの追加があれば優先度をつけて必要があれば次のイテレーションで取り組む)
 
 New And Noteworthy
  機能を明確化したドキュメントをつくる。
  マイルストーン単位で機能ごと確認、機能ごとに確認することで
  フィードバックポイントを絞り込む(要求、話の発散を防ぐ)★

★ポイント
 ・アーキテクチャとチームを密に関係させる
 ・分散開発では無駄をやらない+ロスを最小化することを考える