Index: [Article Count Order] [Thread]

Date:  Tue, 30 May 2000 11:34:11 +0900
From:  "Junzo Hagimoto" <hagimoto@....com>
Subject:  [XP-jp:00429] Re: ObjectDay2000 
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <00c401bfc9df$50799ae0$6e01a8c0@kinta>
References:  <393286E2370.C784SHIGEMI@....com>
Posted:  Tue, 30 May 2000 11:32:33 +0900
X-Mail-Count: 00429

萩本です。

> 平鍋です.ObjectDay2000, 何人かこのメーリングリストの参加者
> とお会いできて,有意義でした.

XPには興味を持っていました。重見さん(元オージス総研)から紹介
してもらいMLに入る事にしました。XP-jpは、とっても参考になりそう
です。

>
>  > ペアプログラミングに関して、「ペアプログラミングを2組で実践
>  > してみて効果的だった」という発言が、なぜだがOO教育のパネル
>  > ディスカッションにおいて、聴衆の方からありました。
>  > ペアプログラミングの効率については疑問視する方が多いと思いま
>  > すが、日本で実践してみた方がおり、成功されているという話を聞
>  > くと、XPを実践してみようという勇気がさらに湧いてきます。
>  > 発言した方がどこの方なのかはわかりません。(名乗らなかったの
>  > で)
> 質問者は,豆蔵(mamezou.com)の萩本さんです.Java, Horb, オブ
> ジェクト指向開発プロセス,方法論(NJK Drop)で有名な方です.

すみませんでした。名乗ったつもりでいました。
佃さんとはパーティの席で偶然お話しましたが、ペアプログラミングに
ついては、残念ながら話題にしませんでしたね。

みなさんに、興味を持っていただいて嬉しいです。
そこで、もう少し、開発のどのような局面にてペアプログラミングを使っ
ているか話をさせてください。みなさんのなんらかの参考になればと思
います。

私が関係しているWeb系商用プロジェクトの開発で、プロト開発サイク
ルと本番開発サイクルの2つのサイクルを実践するように計画してい
ます。
言語はJavaです。
現在は、プロト開発サイクルのシステム共通設計フェーズです。(*注1)

(*注1)詳しくは、
http://www.njk.co.jp/otg/Drop/Drop_v20/part3/chapter10.html
のページの大規模システム型(アプリケーション積み上げ反復戦略)を
参照してください。
(いまさらながら、大規模なんて名前は適切ではなかったかも)

現在、プロトタイプのシステムアーキテクチャの基本構造を決定するに
当たって、「開発者が開発環境に不慣れである」、「要求に対して、ど
の程度のパフォーマンスを出せるか早急に調べ、問題あればプロトの段
階で早めに問題を解決したい」ということから、プリプロト(プリプロ
ト)をシステム構造設計と並行させて行っています。プロトタイプの種別と
しては、Dropで言うところの「システム構造評価プロトタイプ(*注2)」です。

(*注2)
http://www.njk.co.jp/otg/Drop/Drop_v20/part3/chapter12.html#system-arch-valu
e

このプリプロトですが、本番開発におけるシステムアーキテクチャの基
本構造を決定付ける非常に重要なものでしたので、考えられるプロト開
発チームの構成と、そのチームで行った場合のリスクを検討し、できる
だけリスクが少なく、短期間で実質的効果をあげられられるチームをど
うするか考えました。その結果、現時点では以下の2つのチームを作り
プロト開発を行う事にしました。

・Aチーム....
 プリプロト開発においては、システム構造評価プロトを開発、プロト
タイプ開発においては、コンポーネント開発(*注3)を担当する。2名の
チーム。

・Bチーム...
 プリプロト開発においては、システム構造評価プロトを開発、プロト
タイプ開発においては、プリプロトで作成したシステム構造評価プロト
タイプ(*注2)を肉付けする。2名のチーム。
  
(*注3)
http://www.njk.co.jp/otg/Drop/Drop_v20/part3/chapter12.html#component-arch-v
alue

上記のようにプリプロトでは、Aチーム、Bチームにてシステム構造評価
プロトを作成させ、システムアーキテクチャ的に優れたものをプロトタ
イプ開発に採用する事にしています。また、AチームとBチームは、それ
ぞれにペアで設計・プログラミングを行っています。(XPでいうところの
ペアプログラミングでしょうか)また、2つにチームで同じものを開発す
るのいままで何度か実践してきましたが書籍「デッドライン」トムデマ
ルコによってその有効性に対して胸を張って言えるようになったものです。

基本的には、AチームとBチームは協調しながらも競い合う関係。チーム
内の2人は仕事を分担しながらも、チーム内のすべての結果について平
等な責任を持つというもので、暗黙的ルール(ムードでルールを作って
きたので暗黙的)としては次のようなものがあります。

(1)チーム内の2人は、チームの共有財産であるソースの内容を熟知する事。
(2)チームは、チームの成果であるプログラムコードと設計ドキュメントに責任を持
つ事。
(3)チーム内で、設計と実装の担当を分担してもよいが、設計者であっても(1)を実践
する。
(4)AチームとBチームは、プリプロトの期限を厳守するため積極的な情報交換を行う
こと。

このように、プロト開発において、2チーム構成のペアプログラミング
を進めていますが、その成果はとてもよい結果がでています。これを実
践するに当たって4名の工数を使ったのですが、その成果、は以下のよ
うなものになりそうです。まだ、途中なので。

・競い合ったため、短期間で予定以上の機能をプロトに盛り込む事ができ評価に役立
ちそう。(プリプロト開発)
・2チームで開発したため、よいアーキテクチャを議論する際に比較しながら議論が
できた。
・チーム内の2人の中で、助け合いながら設計・実装をやったため、今後の開発にお
けるチーム作りのベースができた。
・2人という小人数で開発を進めるため、非常にスピィーディに事を進める事ができ
ているようだ。

また、チームの成果と行動を考察してみると、下記の事が言えると思います。

・チーム内の2人の作業分担が明確なチームの方が成果を挙げた。
・ドキュメントを実装前に大量に作った(たとえばすべてのクラス図からシーケンス
図まで)チームは、実装と設計に誤差ができ、結果としてもよい成果がでなかった。
・大まかなクラス図を作り、その段階から作業分担して実装し、コードを洗練させた
後に、コードに合った正しいクラス図等ドキュメントを作成したチームの設計とコー
ドの品質は高かった。



ps:平鍋さん、豆蔵へのおみやげのお豆、ありがとう。みんなで食べています。

---
  (株)豆蔵 萩本順三
  http://www.mamezou.com/