offshore agile development in xp

はじめてのオフショア、アジャイル開発

2016.9.02Agile Offshore Development Conference

株式会社チェンジビジョン株式会社永和システムマネジメント

平鍋健児

平鍋健児w ㈱永和システムマネジメント

n  福井市（本社）、神⽥東京（⽀社）、沖縄（事務所）n  「⾦融」、「医療」、「組込みシステム」開発n  「Ruby と Agile」を使ったシステム開発n  Idobata の開発

w 株式会社チェンジビジョンn  福井市（開発部）、上野東京（本社）n  astah* (旧：JUDE) の開発

w 平鍋健児n  UML+マインドマップエディタ astah*の開発n  要求開発アライアンス、理事n  翻訳、XP関連書籍、『リーン開発の本質』

『IMPACT MAPPING』等多数。n  著書『アジャイル開発とスクラム』、『要求開発』

『ソフトウェア開発に役⽴つマインドマップ』

このお話の⽂脈と意図w XPが2000年に⽇本に紹介された。

n XP-jpというサイトを作って⽇本で活動開始(現オブラブ)、現永和東京⽀社の種となる。

n WF疲弊の中にいたぼくは、圧倒的な現場感とプログラミングとモチベーション・顧客重視(not 管理重視)の⼿法に「熱狂」。とにかく⾃分でやってみたかった。

w 2000年、社内の有志少⼈数ではじめ、2002年に中国オフショアにトライ。w このころの苦労と⼯夫をふりかえる。半分は古い話。残りの半分は今でも⽣きている！

（C）Eiwa System Management, Inc 3

今買って読むならこれ！


「オフショアアジャイルの課題と実際　　　　　　　　　　　　　　─ 分散アジャイル開発事例」

初出： UML フォーラム 2003 岡村敏弘/平鍋健児　中国とのオフショアジョイントプロジェクトにおいて、XP（Extreme Programming）を適用した事例を紹介する。

開発対象は、UMLモデリングツールJUDEで、2000年の10月からプロジェクトを開始し、現在に至る。

同じ場所での開発期間と、離れた場所での開発期間の違いや、それぞれどのような困難や利点があったかを中心に説明する。

コミュニケーションが困難な状況においてアジャイルな開発を行う場合の課題と解決策を探る。

アブストラクト


アジェンダ

w 経緯と方針（中国・上海の状況を交えて）

w XP概要

w プロジェクト概要

w レポート

w 考察


発端

w  上海視察帰りの社長曰く，n  中国のソフトウェア会社と共同開発

をせよ．

n  中国は人件費が安い点で注目されているが，実際に上海に行ってみると技術者のエネルギーはすごい．優秀な人材がたくさんいる．単に人的資源の調達場所としてではなく，優秀な技術者と友好関係を結びたい．また，今から爆発するであろう中国市場も視野に入れたい．

n  現在開発中のJude(UMLエディタ)の開発を加速．


中国・上海の状況

今回ざっくり割愛オリジナルは、こちらを参照

http://www.slideshare.net/hiranabe/distributed-agile-using-uml


中国とのジョイント開発の大方針

w 中国を労働力リソースとは見ない

w 将来の展開を見据えた信頼関係作り

w 共同開発の２つの方向の選択肢

n 設計と製造の分離　… UMLでの仕様I/F n 密なチームの結成 … XPチーム採用


具体方針

w XPチームを結成し，UMLエディタを開発する．

w チームを醸成する．UMLに精通する．

w オブジェクト指向開発ノウハウを伝授する．

w 将来の「設計と製造の分離」にも備える．

w 分散開発のプロセスモデルを探る．

w 両社のWin-Winを確認する宣言書を作成．

当時こういう言い方が流行っていた

重視したのは思いと共通のゴール作り。


2002年9月23日

私たち、永和システムマネジメント、SuperV、大陸貿易開発、上坂会計の四社は、日本と中国での共同ソフトウェア開発において、新しいビジネス、新しい価値を創造する活動を行います。この活動にあたっては、以下を共通の原則として行動します。

1. チャレンジへの若い情熱（青）2. 出発当初の初心忘るべからず(義)

3. 信頼と友情を基礎にしたアライアンス（愛）4. 自己実現(夢)

私たちの夢：　４つのWinが第５のWinを創造する。

福井宣言

多分、アジャイル宣言に影響を受けている。中国なので、漢字で「思い」を共通の理解とした。


アジェンダ


w XP概要


w レポート

w 考察


XPとは

w eXtreme Programming w コーディングとテストに重点

w 初期設計よりも漸進的再設計

w 明確な「4つの価値」,「12のプラクティス」を示す

w ソフトウェア開発は製造工程ではない．対話を基礎に置いた新しいパラダイム．

Kent Beck, 1999 Extreme Programming Explained - Embrace Change （『XPエクストリーム・プログラミング入門 - ソフトウェア開発の究極の手法』）

ここもざっくり飛ばします。本（前のページで紹介した新訳）を読んでね。


伝統的な開発


XPの開発


4つの価値

w Communication(コミュニケーション)

w Simplicity(シンプルさ)

w Feedback(フィードバック)

w Courage(勇気)

Communication +Simplicity+Feedback = Courage


12のプラクティス

w  Planning Game n  計画ゲーム

w  Small Releases n  ちいさなリリース

w  Metaphor n  メタファー

w  Simple Design n  シンプルデザイン

w  Testing n  テスティング

w  Refactoring n  リファクタリング

w  Pair Programming n  ペアプログラミング

w  Collective Ownership n  共同所有権

w  Continuous Integration n  継続的インテグレーション

w  40-Hour Week n  週４０時間

w  On-site Customer n  オンサイト顧客

w  Coding Standard n  コーディング標準

※ 14, 13, 19 などと統廃合が起こっているが，ここではオリジナルの12を挙げる


XP Processリリース開発

イテレ

シ

ン

リリ

ス計画

受入れテスト

2～3ヶ月

イテレーション

・タスク

・タスク

・・

イテレ

シ

ン

計画

受入れテスト

2～3週間

ストーリーストーリー

タスク

スタンダ

プ

ミ

テ

ング

ユニ

トテスト

1～2日

ペア

プログラミング

・・・・・

ペアプログラミング

テスト作成

ユニ

トテスト

2～3時間

プログラミング

XPの開発の流れ

ユ

ザ

スト

リ

リリ

ス・・・・・・

リフ

クタリン

グ

インテグレーション

実行可能リリース

インテグレーション

ストーリーカード

タスクーカード

w プロジェクトはリリースの連続

n １リリースは２~３ヶ月

w リリースはイテレーションの連続

n イテレーションは２~３週間

w イテレーションはタスクからなる

n タスクは１~２日

w タスクはペアによって開発される

n 毎朝のスタンドアップミーティング

n テストファーストによる開発


アジェンダ


w XP概要


w レポート

w 考察


開発対象Jude

w UMLモデリングツール

w Javaアプリケーション

w 規模（現在） n クラス数：1180

n 全NCSS：約9万行（≒コメントや空行以外）

Packages Classes Methods NCSS per

38 1180 9075 88826 Project 31 239 2338 Package

8 75 Class 10 Method

プロジェクト概要

今の astah は、軽く10倍になっている


ビジョン

１．Jude竹バージョンを開発しリリースすること

２．信頼関係を構築し、日本と中国で高品質のソフトウェアを共同開発するモデル（ビジネス、プロセス）を見つけること

 デファクトスタンダード

２．中国アライアンス

１．Jude

Jude梅

Jude竹

Jude松

  クリエイティブで生産性の高いチーム

  コアとなる機能を装備

  将来の展開に耐えるレベルに拡張

  業界特化商品  カスタマイズパートナ

 アーキテクチャの確立 基本機能の実装

  Win-Win関係

  信頼関係


当社 Superv(上海）

体制

w 中国３名、日本３名の開発チーム

開発チーム

Director：平鍋（擬似顧客、コーチ）

GPM：Toshi （擬似顧客代理）

Masa （プログラマ）

２９才、開発経験７年

Midori （プログラマ）

３３才、開発経験８年

PM: Rock （マネージャ、プログラマ）

２７才、開発経験４年Wenny （プログラマ）

２８才、開発経験５年

Yves （プログラマ）

２３才、開発経験１年

Technical Manager：Jessy（コーチ）

PM: Toshi （マネージャ、プログラマ）

３０才、開発経験６年


スケジュール

w Startup Phaseで４つの図サポートを追加する

w Elaboration Phaseで他の基盤機能を追加する

年⽉ 10 11 12 1

2002 20036 7 8 92 3 4 5

Release4他基盤機能の拡張

Release1ステートチャート図、アクティビティ図追加

準備

Release2シーケンス図、

コラボレーション図追加

Release3他基盤機能の拡張

Startup phase では、project velocityの把握、ナレッジ共有、相互理解、コミュニケーションに焦点をあてる

Startup Phase

Elaboration Phase


開発場所

w 中国で一緒に開発スタート → 分散開発

w 日本で一緒に開発 → 分散開発

１０１１１２１２３

Release1 Release2

日本

上海

当社

当社

当社

SV

SuperVSuperV

準備 →

分散合同分散合同分散


w  「XPをベースに短期繰り返し型で開発する」

w  課題

n  どう情報共有するか

n  どう品質を維持するか

n  どうリスクを軽減するか

w  XPの採用

n  密なコミュニケーション

n  ペアプログラミング・ユニットテストによる品質維持

n  短期リリースと舵取りによるリスク軽減

w  工夫した点

n  モデルテスト、コマンドテスト、ストーリテスト

n  Reflection Sheet、Evaluation Sheetで改善

プロセス１


プロセス２

Release1(3 months)

Iteration2(1 weeks)

Iteration1(1 weeks)

Simple UML

Story1

Rel.2

Meta model

Iter

atio

n E

valu

atio

n Story2-1

Story2-N It

erat

ion

Eva

luat

ion

Iteration3(1 weeks)

Story5-1

Story5-N

Iter

atio

n E

valu

atio

n

Presentation

Model Test

Model Test

Model Test

Command Test

Command Test

IterationN(1 weeks)

Story Test

Iter

atio

n E

valu

atio

n

Rel

ease

Eva

luat

ion

Evaluation Sheet Improved Process

Rel

ease

Pla

nnin

g

Iter

atio

n Pl

anni

ng

Iter

atio

n Pl

anni

ng

Iter

atio

n Pl

anni

ng

Iter

atio

n Pl

anni

ng

Reflection Sheet Tracking Sheet

w Release：三ヶ月単位で大きな計画＋機能開発＋評価を行う

w Iteration：計画＋機能開発＋評価を一週間単位で繰り返す

イテレーション0で、モデルを作っている。

イテレーションNは、手動テストに専念。

ふりかえりが肝！


ツール・環境

統合開発環境 Eclipse 構成管理 CVS、WinCVS 情報共有 Swiki 会話 MSN Messenger ユニットテスト JUnitビルドツール Ant OS Windows2000､XP コンパイラ J2SE 1.4.1

いまはもう古いので見ないでね。


アジェンダ


w XP概要


w レポート

w 考察


導入

１０１１１２１２３

Release1 Release2

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 11

日本

上海

当社

当社

当社

SV

SuperVSuperV

導入 →

w 開発開始前の準備w  計画共有、ストーリカード準備、環境準備、体験課題



環境準備

w 「コミュニケーションに適した環境を準備」ホ

ワイ

トボ

ード

タスク表を貼る壁

プリンタ

ホワイトボードを持つチームの部屋

お菓子


XP体験課題

M1 M2 M3 M4 M5 M6分析されたクラス構成 C B B A B B依存関係の局所化 B A B A A A理解しやすさ C B A A A B命名センス A B A A A Aコメント充実度 B A C A C Cテスト比率 B B B A A Aコーディング標準 C B B B B B

「簡単な課題で、プロジェクトでの価値観を共有」

w 課題：「ボーリングの点数計算プログラム」

w 狙いと効果

n XP予行（ユニットテスト、タスク分割と見積もり）

n プロジェクトでの価値観共有l  理解しやすさ重視

l  品質重視

n メンバの技量把握

n コーディング規約注意

w 期間：１日

各自のプログラム評価結果

現在でも新しくチームに入った人や採用時に、「スキル合わせ」としてやっている。


アーキテクチャ１

w 「共通語のUMLでアーキテクチャを共有」

jcontrol

jm odel

jview

jsystem

jutil<<globalutility>>

jview Elem ent

resource

Jude

StartupJudeapplication.m ain()m ethodishere.

C om m ands&M odes.Editm odelandcontrolview .

System .G lobal,SecurityM anager,System Property

View .Fram e&D ialogs

View elem ents.Hasview m odelandUpdatedrawing

Jude'sM odels(Presentations)

Properties,Help,Im ages,M essages

Utilities

JP.co.esm.caddies.jomt• パッケージの責務と依存関係中心に理解

説明UMLの例


Overview of Golf(Jude Architecture)

Control

Model

View

Com m andListener<<Interface>>

EntityStoreEvent

M odelUIView

G roupU IView

C om m andFactory

Application

Command

C om m andEvent

C om m andM anager<<singleton>>

C om m andRunner

11new

listen

JTree(from swing)

JTreeUIView

G C anvas(from draw)

G C anvasUIView

listen

M ode JM enuBar(from swing)

UIView

** 0..10..1

G olfAction

0..*

new

new

new

Action(from swing)

EntityClipboard

edit

EntityStore new

edit

StateEditable(from undo)

<<Interface>>

0..*0..*

Com m unicationbetw eenView andC ontrolisexecutedwithinC om m andEvent.View generatesC om m andEvent.

AC hangeofM odeisnotifiedtoView w ithinEntityStoreEvent.

C om m andeditsM odel.ItalsooperatesM odeandUI.

0..*

アーキテクチャ２

w 「Judeは、MVCのフレームワーク上に構築」


Release1

テストの種類

Iteration2 Iteration1

モデル開発機能開発• コントローラ• ビュー

モデルテストモデルテスト

コマンドテスト

IterationN

ストーリテスト

Model Test


モデルテスト

(JUnit) 内部で持っているモデル（UMLメタモデルなど）が正しいかを確認する


（JUnit）

アプリケーションを起動した状態でコマンドを送り、コマンドが正しく実行できるかを確認する

ストーリテスト

（手動）

ユーザストーリを正しく実行できるかを目視で確認する


Release1 合同開発

１０１１１２１２３

Release1 Release2

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 11

日本

上海

当社

当社

当社

SV

SuperVSuperV

準備 →



Releaseプランニングw 「ざっくりと、一緒に計画する」

w 準備していったStoryカードとStoryリストを利用

w 合同開発中に一通りの開発を一緒に行う

見積もり（理想日）

Storyのリスト

どれからやるか

どんな機能を開発したいか


第一イテレーション

w とにかくやってみる

w できる限りコミュニケーションする


Iterationプランニング

w タスク内容

n ステートチャート図のモデル開発

n ステートチャート図の生成機能開発

l （一つ基本機能を先行開発）

w タスク分割とサインアップ


開発

w 「ペアプロがチーム内ナレッジ共有に効果大」

w UMLで開発対象の概略理解

n UMLメタモデル等のクラス図、オブジェクト図

w ペアプログラミング

n 新しいことに対する勇気、そして理解

l  アーキテクチャ

l  開発環境

n 会話促進

n ソースコードで解りあう

w ユニットテスト

n 習慣化


トラッキングシート

w 計画したタスク全て完了

w Team Velocity = 12.2 Points w Test = 100% （168 cases）


リフレクションシート

w 「このIterationを振り返り、改善」

Keep These Try These w Good mood w Make jokes w Talk a lot w No over work w Communication by writing and drawing w Avoiding to one-way communication w Without projector w Pair Programming w Stand up meeting

w Dash out the completed task w Eat some sweets w Put list of story on the wall w Pair up with different nationality w Take a 15 minutes rest after lunch w Open the window during lunch (by Yves) w Tracking on wiki


第二イテレーション

w 機能の開発

n Storyカードで機能理解

n ほぼ全ペアの組み合わせ実施

n 途中で新たなストーリ７つ追加

n 全タスク開発完了


開発風景


中国余談

w プラスn 時差１時間

n 漢字、ブロークンな英語

n 健康志向、週４０時間労働

w マイナス

n ビザ、連休

n 電話、ネットワーク不安定

n 交通

w 両方

n 食事


Release1 分散開発

１０１１１２１２３

Release1 Release2

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 11

日本

上海

当社

当社

当社

SV

SuperVSuperV

準備 →



分散開発

w 分散でも大きな分担割をせずXP継続

w 変化・工夫

n あらかじめStoryカードを一緒に作成、理解

n プランニングは、全員でのチャット

n トラッキング情報は、壁ではなくwikiで共有

n スタンドアップミーティングは、各社で実施

n 不明点、アイデアなどは、必要なときにその都度チャット

n ペアプロは、継続（奇数人になり減少）


ここから簡単にWebを編集

Wikiによる情報共有サイトマップw Release 1

n  スケジュール（期間分割と大雑把な見通し）

n  ストーリー一覧（このリリースの開発対象）

l  ストーリーカード（必要なストーリーのみ）

n  Iteration1 l  Reflection Sheet（前回の反省）

l  Tracking Sheetl  Team Velocity l  テスト結果（テストケース数と結果）

n  Iteration2 n  ・・・・・

w Release 2 w Release 3 w バグ情報一覧

w 改善項目一覧

w Daily自動テスト結果集計

w 開発のヒント集（開発注意点など）

w ダウンロード数推移

Edit


実践プラクティス

実施プラクティスどのように実践したか

○計画ゲーム開発者全員で見積もり、サインアップ。

ストーリーカードにより機能を理解。タスクカードは作成せず。

× メタファー特に準備せず。

○ ちいさなリリース２週間単位でリリース。

○ シンプルデザイン機能の実装に必要な設計のみに集中。

○ テスティングユニットテストを実践。テスト駆動は未定着。

△ リファクタリング気づいたときになるべく実践。必要意識高い。余裕必要。

○ ペアプログラミングよく実践した。常にではなく、デバッグ時は1人。

○ 共同所有権どのファイルも誰でも編集可能。

○ 継続的インテグレーション毎日インテグレーション。毎日自動テスト。

○ 週４０時間ほぼ残業ゼロだった。最近はがんばりペース。

× オンサイト顧客意見がまとまらない場合など、擬似顧客が決定。

○ コーディング標準 ObjectClubバージョンの標準遵守。Eclipseの自動フォーマット。

○ Reflection、Evaluation Iteration毎にReflectionシート作成（５分）。

Release毎にEvaluationSheet記入。→ 改善意識向上。

○ モデルテスト、コマンドテスト、ストーリテスト

テストの種類を３つ用意。コマンドのテストサポートクラス利用。

特別

特別


トラブルと対処

w Visa取得遅れによる出張延期n → 準備課題など

w 仕様誤解２，３度n 慣れによる仕様確認不足が原因

n → そのイテレーション内に回復

n → 複雑なものはwiki上にイメージと詳細な記述追加

w 正月休みのずれ＋１人ハネムーンn → 他のメンバがカバーし、問題なし

w ネットワーク不安定でチャット不可n → 他のインスタントメッセンジャで対処


Release１全体

X’m

as v

ersi

on w ８回のイテレーションを完了

n 平均TeamVelocity = 12.2 n テストケース数 = 404

n 完了したストーリー数 = 約100

n ステートチャート図とアクティビティ図追加

n 他いくつかの改善項目を完了

n 合同開発・分散開発共に順調に進行

w X’masバージョンを急遽リリースn 予定外、２日で対応

n 外部へのリリースで、顧客視点の再認識


アジェンダ


w XP概要


w レポート

w 考察


分散開発と担当割

横に大きく割る縦に大きく割る一緒に開発する

例アプリを日本、

モデルを中国

A図を日本、

B図を中国

A図を一緒に開発

頻繁なリリース × △ ○

担当タスク間の依存あり少ないあり

コミュニケーション疎疎密

必要知識少中多

機能仕様の統一感 ○ △ ○

品質 ○ ○ ◎

モチベーション △ ○ ◎

w Judeプロジェクトでは、“一緒に開発”を継続


ツールとアジャイル開発

w 「分散アジャイル開発はツールにも支えられる」

種類ツール効果

開発 Eclipse プログラミングが楽。ソースを追うのが楽。テストが楽。リファクタリングが楽。

構成管理 CVS、WinCVS ソースコード共有が楽。

会話インスタントメッセンジャー（MSNMessenger他）

情報・考えを伝えるのがメールに比べ格段に楽。

情報共有 Swiki、TWiki、PukiWiki他非常に手軽に情報共有できた。

XP管理 XPlanner、XpTrackerPlugin（TWiki plugin）

WebベースのXPプロジェクトサポートシステム。（Judeプロジェクトでは未使用）

ユニットテスト JUnit テストが楽。

ビルドツール Ant 頻繁なリリースが楽。

遠隔ペアプロ Sangam(Eclipse plugin）離れた人とのペアプロの可能性。

（まだ不安定）

直接会って話をする、壁に貼る、が一番。それに近づける。


UMLの役割

高い表現力・伝達力と厳密さをもった標準言語

↓

ソフトウェアの設計をすばやく共有

↓

アライアンスとスピード時代の開発をスムーズに

w 今回の開発でのUML利用n 開発対象Judeのアーキテクチャ共有

n モデル（UMLメタモデル含む）の設計

n 簡単な設計アイデアの交換


プロジェクトの特性

Judeプロジェクトについての、

分散アジャイル開発のプラス要因

w 自分が顧客視点を持てた（UMLツールの利用者）

w 機能追加が主で大規模な設計が不要だった

w 参考ツールが存在し、要求仕様を理解しやすかった

w 一部モデルに関する詳細な仕様書が存在した

w 日本と中国との開発だった（時差など有利）

w 自社ソフトウェアの開発だった


うまくいったことと課題

w うまくいったことn 導入課題での価値観共有

n XPでのナレッジ共有、モチベーション維持

n リフレクションシートでの改善・改善意識

n メールではなくチャットでのリアルタイムな対話

n Wikiでのプロジェクト情報共有

w 課題

n コマンドテストの軽量化（テスト実行時間短縮、分割など）

n 顧客巻き込み

n リファクタリングとテストの時間確保

n プランニングゲームの時間短縮


今回の事例のポイント

w JudeをXPで中国と共同開発

w あえて大きな役割分担せず、“一緒に開発”

w 同じ場所でチーム開発開始

w ナレッジ共有、モチベーション維持

w 分散開発ではコミュニケーションツール活用

w UMLは重要な共通語の一つ

w 密なチーム・信頼関係を構築


XPと信頼

XP 信頼XPは、信頼を築く

XPは、信頼を基礎とする


紹介

図

ユースケース図

クラス図

シーケンス図

コラボレーション図

ステートチャート図

アクティビティ図

入力 Javaソース読み込み

出力

図のプリンタ出力

Javaスケルトンコード出力

PNG、JPEG出力

Javadoc形式のHtml出力

w 機能・特徴n  UML1.4サポート

n  無限回UNDO/REDO（編集の取り消し、やり直し）

n  大きな図をすばやく移動できる全体マップビュー

n  クラス図自動生成

n  Microsoft Office® への図イメージ貼付け

n  右ドラッグによる斜め方向スクロール

n  ステレオタイプ毎の色設定

http://ObjectClub.esm.co.jp/Jude/ にて無償公開中。

「真のカスタマからのコメントを

ぜひお寄せください」

p.60

その10年後(2010年〜現在)


まとめ

w 10年以上続いている、アジャイルオフショア事例です。

w  ツールは進歩しても、大事な変わらないものが多い。これらを中心にお話しました（以下）。

w 特に立ち上げ時はコミュニケーション（人を知る）が大事。部屋を一緒にする、ペアプロ、など期間を。知らない人とメールでコミュニケーションしない。

w 「ふりかえり」が超重要。分かれていても、KPTシートを交換するなど、本音の会話を。

w 開発方針や、全体絵、会社としての思い、などを最初に語ろう。

w (特にこの開発では)絵、UML、による仕様の「理解共有」(Shared Understanding)が大事。

offshore agile development in xp

Software