|
|
| 概要 |
|
| メンバ |
| メンバ名 |
開発経験 |
j2ee経験 |
oo経験 |
役割 |
| sh |
経験豊富 |
２年 |
１年 |
マネジャ、プログラマ |
| kh |
経験豊富 |
１年 |
１０年 |
コーチ、トラッカ |
| yt |
入社３年 |
２年 |
２年 |
プログラマ |
| st |
入社２年 |
１年 |
１年 |
プログラマ |
| kk |
新人 |
－ |
－ |
プログラマ |
| ay |
経験豊富 |
－ |
－ |
（擬似）顧客 |
今回は新入社員がいたり、オブジェクト指向開発の経験がなかったり、
経験が浅かったりと、ちょっと頼りないメンバ６名で構成しました。
でも、実際の開発現場に近いことは確かです。
唯一、全員がなんらかのjavaプログラムは書いたことが頼みの綱です。
また、仕様に関しては顧客役に一名参加してもらいました。顧客には、
フルタイムではなく、週に二日、作業場所を共にしてもらいました。
【戻る】
|
| スケジュール |
実践期間は、２００１年７月の１ヶ月間としました。
リリース計画では、開発要件からストーリを切り出し、各イテレーションに
ストーリを割り当ててスケジュールしました。
実践期間の都合で、１イテレーション＝１週間（本来は２週間程度）、
リリースは全体で１回のみとしました。
【戻る】
|
| 利用ツール，ミドルウェア |
以下のようなソフトウェアツールを使って，システムを構成しました．
- os - windows 98, 2000
- webサーバ/servletエンジン - tomcat 3.2
- ビルドツール - ant1.3
- ユニットテスト - junit 3.7
- ソース管理 - wincvs 1.2
- コンパイラ - java sdk 1.3
- クライアント - web browser(ie5.x)
一般的なservlet/jspによるwebアプリケーションです．
データベース製品は利用せず，簡易なcsv形式のファイル
を用いて永続性を実現しています．
【戻る】
|
| ストーリ |
開発要件は、個人の基本情報、患者情報や健診情報、職員情報の検索、表示、登録、変更としました。
特殊機能として、血縁情報を追加して親子を順次検索できる機能も加えました。
これらの開発要件をストーリとして、以下のように切り出し，カードに書きました。
ストーリは，「誰にでも分かる仕様書」でないことに注意してください．
顧客が書き，ストーリの説明に参加した全員が，このカードを見れば
会話のことを思い出すことができます．また，質問があれば，このカード
を持って顧客とさらに会話をすることができます．
- ｉｄ検索機能 【スケジュール】
・人物のｉｄを入力して検索することができる。
・データが見つかった場合は詳細情報画面にデータを表示する。
・見つからなかった場合は検索画面に戻る。
・見つからなかったというメッセージを表示する。
- 条件検索機能 【スケジュール】
・条件を入力して検索することができる。
・データが見つかった場合は検索結果を一覧画面に表示する。
・検索条件は、ふりがな、氏名、性別、生年月日、電話番号、属性をａｎｄ条件で検索する。
・条件が１つも指定されない場合は全件表示とする。
・一覧表示から詳細情報画面へ遷移する。
- 登録機能 【スケジュール】
・登録画面からデータ（基本情報）を登録することができる。
・患者情報、健診患者情報、職員情報を選択して登録できる。
・登録画面（４画面）は任意に画面を切替えることができる。
・登録実行時に、確認画面を表示する。
・各種データはバージョン管理する。
- 血縁関係の追加 【スケジュール】
・基本情報に父親、母親、配偶者の情報を追加する。
・詳細情報画面、登録画面（基本情報）、登録確認画面に血縁関係を追加する。
- トランザクション機能 【スケジュール】
・各種情報のトランザクションを一元管理して、情報矛盾をガードする。
- ソート表示機能（一覧画面） 【スケジュール】
・一覧画面にソート表示を追加する。
・ソート条件は、ｉｄ，ふりがな，生年月日とする。
- ログイン機能 【スケジュール】
・ログイン画面を作成して、セキュリティ機能を追加する。
・ログインなしによる各種参照画面、登録画面へのアクセスをガードする。
【戻る】
|
| プラクティスの実践 |
xp には14のプラクティス(実践項目)があります．それらを，今回の
プロジェクトでどのように実行したか，をまとめます．
- 計画ゲーム
・（擬似）顧客を交えて，ストーリーカードを利用して行った．
・リリース計画は一回のみ．イテレーション計画は４回行った.
- 小さなリリース
・リリースは一回のみ．
- メタファー
・今回行わず（思いつかなかった）
- シンプルデザイン
・徹した．できるだけ明日への設計をしなかった．
- テスティング
・ユニットテストは，モデルクラスについてほぼ全クラス行った．
・servlet/jspについては，行えなかった．
・受け入れテストは，httpunitを用いて行った．
- リファクタリング
・適宜行った．
- オープンワークスペース
・席の並び替えを行い，できるだけ近くで作業をするようにした．
・オープンなスペースもあった．
- ペアプログラミング
・徹底して行った．すべての製品コードはペアによって書かれた．
- 共同所有権
・cvsを利用し，全員が自由に変更した．
- 継続的インテグレーション
・今回は統合マシンによる自動ビルドや自動テストは行えなかった．
- 週４０時間
・結果的に達成できた．
- オンサイト顧客
・擬似顧客をオンサイトに置いた．ただし，週に２日のみ．
- コーディング標準
・オブジェクト倶楽部バージョンのコーディング標準を採用した．
- 日ごとのデータベース移行
・データベース製品は利用しなかったが，常に最新スキーマを用いた．
【戻る】
|
| イテレーションの記録 |
イテレーション終了時には、イテレーション評価をすると共に、
作業量や実装速度を算出しました。
また、イテレーション毎の感想等は、付録ａ．イテレーションの考察
を参照してください。
* リリース計画
--------------------------------------------
ストーリー名: 検索
データの一部を入力して，検索することができる．
見つかった人のデータを表示する．
・複数見つかれば一覧表示
・1名なら詳細表示
・0名なら登録画面となる
--------------------------------------------
見積り: 2理想週(10理想日)
--------------------------------------------
ストーリー名: 登録
登録画面から基本データを登録できる．さらに，
患者，職員，検診患者
を選んで詳細を登録できる．画面フォーム，遷移は別途定義．
--------------------------------------------
見積り: 2理想週(10理想日)
--------------------------------------------
ストーリー名: 血縁検索
人物を選んで「1親等」内の人物をツリー表示できる．
ツリーは辿れる．
--------------------------------------------
見積り: 2理想週(10理想日)
全体で３週間，3イテレーションとする．
上から順に1イテレーション1週間とする．
我々の1週間の保有人日は，5名 x 1週間で５人週．
負荷係数として，2.5 を採用し，一週間で２理想週の作業を行う．
こうすると，ストーリー1つにつき一週間(1イテレーション)の計算
となる．
|
* 第１イテレーション
・イテレーションに入力されたストーリー
--------------------------------------------
ストーリー名: 検索
データの一部を入力して，検索することができる．
見つかった人のデータを表示する．
・複数見つかれば一覧表示
・1名なら詳細表示
・0名なら登録画面となる
--------------------------------------------
見積り: 2理想週(10理想日)
このストーリーは，途中で結局2つのストーリーになった．
--------------------------------------------
ストーリー名: id検索
人物のidを入力して検索することができる．
データが見つかった場合は情報表示画面に
データを表示する．
見つからなかった場合は，検索画面に戻る．
見つからなかったというメッセージを表示する．
--------------------------------------------
--------------------------------------------
ストーリー名: 条件検索
条件を入力して検索することができる．
検索結果を一覧表示する．
検索条件は，
ふりがな，氏名，性別，生年月日，電話番号，属性
の1つ以上の入力を and 条件で検索する．
条件が1つも見つからない場合，全件表示．
--------------------------------------------
見積り: ２つで2理想週(10理想日)
・ブレークダウンされたタスクと，見積り値
--------------------------------------------
第1イテレーション(7/3 - 7/9) 計画
--------------------------------------------
1. cvs 環境整備(0.5) ... done 7/4
sh - 0.5
2. コーディング規約 ... done 7/4
---
3. 画面設計，遷移 ... done 7/4
ay(顧客)に任せる
4. 人物・患者等のモデルクラス作成(1.0) ... done 7/5
yt - 1.0
5. モデルストア(簡易csvファイルdbメカニズム)の仕組み(1.0) ... done 7/6
kh - 1.0
6. 検索サーブレット(2.0) ... done 7/9
sh - 1.0
st - 1.0
7. 表示用jsp(1.5) ... done 7/9
yt - 0.5
st - 0.5
kk - 0.5
8. html 検索フォームファイル(1.0) ... done 7/9
kk - 1.0
--------------------------------------------
・メトリクス
==========================================
カテゴリ クラス数 テストクラス数
---------------------------------------------
model 4 3
servlet 3 0
jsp 2 0
html 2 0
---------------------------------------------
==========================================
受入テスト数 3 件
---------------------------------------------
ユニットテスト成功 100%
受入テスト成功 100%
---------------------------------------------
==========================================
実時間: 1 週間 = 5 日/イテレーション
人数: 5名
ストーリの見積り: 10 理想日/イテレーション
全タスクの見積り: 7 理想日/イテレーション(=プロジェクト速度)
実作業人日: 25人日
負荷係数: 3.6
---------------------------------------------
３理想日あまったが，実際は作業がのびた．
|
* 第2イテレーション
・イテレーションに入力されたストーリー
--------------------------------------------
ストーリー名: 登録
登録画面から基本データを登録できる．さらに，
患者，職員，検診患者
を選んで詳細を登録できる．画面フォーム，遷移は別途定義．
--------------------------------------------
見積り: 2理想週
・ブレークダウンされたタスクと，見積り値
--------------------------------------------
第2イテレーション(7/10 - 7/16) 計画
→ 結局，(7/10 - 7/17)となった．
--------------------------------------------
1. 患者・検診患者・職員クラス ... done 7/11
sh - 1.0
2. 基本jsp + servlet ... done 7/17
(基本情報・確認・エラー)
kk - 1.5
3. 詳細情報 jsp + servlet ... done 7/17
st - 1.5
4. mpilotmodelstore 修正 ... done 7/13
yt - 1.0
5. person 修正 ... done 7/13
sh - 0.2
6. servlet 修正・jsp修正 ... done 7/13
yt - 0.3
7. 用語辞書(日英) ... don 7/11
yt - 0.2
8. 患者，人物，参照方向の変更 ... 7/12 追加・7/14 done
sh
--------------------------------------------
・メトリクス
今回(前回)
==========================================
カテゴリ クラス数 テストクラス数
---------------------------------------------
model 8(4) 7(3)
servlet 10(3) 0(0)
jsp 8(2) 0(0)
html 2(2) 0(0)
---------------------------------------------
==========================================
受入テスト数 5(3)
---------------------------------------------
ユニットテスト成功 100%(100%)
受入テスト成功 100%(100%)
---------------------------------------------
==========================================
実時間: 1 週間 = 5 日/イテレーション
人数: 4名
ストーリの見積り: 10 理想日/イテレーション
全タスクの見積り: 5.7 理想日/イテレーション
実作業人日: 20人日
負荷係数: 3.5
---------------------------------------------
人数が減ったが，タスクブレークダウン後の全
見積値も減ったのでこのまま進める．
|
* 第3イテレーション
・イテレーションに入力されたストーリー
--------------------------------------------
ストーリー名: 血縁検索
人物を選んで「1親等」内の人物をツリー表示できる．
ツリーは辿れる．
--------------------------------------------
見積り: 2理想週
・ブレークダウンされたタスクと，見積り値
--------------------------------------------
第3イテレーション(7/17 - 7/23) 計画
→ 結局，(7/17 - 7/20)となった．
--------------------------------------------
画面変更 + 不正入力チェック+エラー処理
1. 一覧画面 ... done 7/18
2. 基本入力 ... done 7/19
sh - 1.0(上記2つ合わせて)
3. 詳細表示 ... done 7/19
yn - 1.0
4. 検患入力 ... done 7/19
5. 職員入力 ... done 7/19
kk - 1.0(上記2つ合わせて)
6. 入力確認 ... done 7/18
st - 1.0
7. mpilotmodelstore ... done 7/18
8. person ... done 7/18
9. mpilotutil ... done 7/18
yt - 1.0(上記3つ合わせて)
10. xmlgenerator(クラス，サーブレット) ... done
yt - 1.0
--------------------------------------------
・メトリクス
今回(前回)
==========================================
カテゴリ クラス数 テストクラス数
---------------------------------------------
model 9(8) 8(7)
servlet 12(10) 0(0)
jsp 9(8) 0(0)
html 5(2) 0(0)
---------------------------------------------
==========================================
受入テスト数 5(5)
---------------------------------------------
ユニットテスト成功 100%(100%)
受入テスト成功 100%(100%)
---------------------------------------------
==========================================
実時間: 0.8 週間 = 4 日/イテレーション
人数: 5名
ストーリの見積り: 10 理想日/イテレーション
全タスクの見積り: 6 理想日/イテレーション
プロジェクト速度: 6 理想日/イテレーション
実作業人日: 20人日
負荷係数: 2
---------------------------------------------
|
* 第4イテレーション(予定外)
・イテレーションに入力されたストーリー
--------------------------------------------
ストーリー名: ソート
検索結果をソートする．ソートは，あいうえお順，
生年月日順．
--------------------------------------------
見積り: 2理想日
--------------------------------------------
ストーリー名: ログイン
ユーザは，セッションに入るためにidとパスワードで
ログインする．一度ログインしたら，もうログインの
必要はない．
--------------------------------------------
見積り: 3理想日
・ブレークダウンされたタスクと，見積り値
--------------------------------------------
第4イテレーション(7/23 - 7/31) 計画
→ 結局，(7/23 - 7/25)となった．はやく終った．
--------------------------------------------
1. (ソート) list.jsp ... done 7/25
2. (ソート) categorysearchservlet .. done 7/25
st - 1.5(上記2つ合わせて)
3. (ログイン) search.jsp(search.html)
リンクまわり/セッションまわり ... done 7/25
4. (ログイン) loginservlet ... done 7/25
yt - 1.5(上記2つ合わせて)
5. (ログイン) user.java, mpilotmodelstore ... done 7/24
kk - 1.5
--------------------------------------------
・メトリクス
今回(前回)
==========================================
カテゴリ クラス数 テストクラス数
---------------------------------------------
model 11(9) 9(8)
servlet 13(12) 0(0)
jsp 12(9) 0(0)
html 8(5) 0(0)
---------------------------------------------
==========================================
受入テスト数 5(5)
---------------------------------------------
ユニットテスト成功 100%(100%)
受入テスト成功 100%(100%)
---------------------------------------------
==========================================
実時間: 0.6 週間 = 3 日/イテレーション
人数: 4名
ストーリの見積り: 5 理想日/イテレーション
全タスクの見積り: 4.5 理想日/イテレーション
プロジェクト速度: 4.5 理想日/イテレーション
実作業人日: 12人日
負荷係数: 2.1
---------------------------------------------
|
* 全体
==================================
実作業人日 77
製品クラス数 44
製品loc 7314
テストloc 1655
全loc 8969
製品loc/人月 1899
全loc/人月 2329
==================================
( loc = line of code コメント・空行ぬきの行数 )
※全作業時間の８０％がペアプログラミング時間となっていた。
|
|
プロジェクト速度が一定していないのは，イテレーションによってメンバーの増減や利用可能日数が違った
ため．ストーリー見積とタスク見積(プロジェクト速度)が一致しないのは，ブレークダウンにより問題がよ
り簡単であることが分かったため．本来一致すべきだが，メンバーの増減があったため，余分のタスクを入
れなかった．負荷係数は，通常のxpでは３程度から始めることが推奨されている．
今回は最初は 3.6 であり、最終イテレーションでは 2.7 になった．
結果的に徐々に下がったことになる．
|
クラス数には，servlet/jsp/htmlのすべてを含む．
ユニットテストは，モデルクラス(servletやjsp以外のjavabeans)にしか用意しなかった．
受け入れテストは，全体をカバーするだけの工数が顧客に足らなかった．
|
| 風景 |
画面遷移はこんな感じ。必需品です。
いつも、この図を使って討論していた。
|
ｓｈ：「見られるとパンチし辛いなあ....」(^-^;
「 (ムム！) 間違っちゃったよ！..」(t-t)
ｋｋ：「 .... 」(@_@)
|
ｙｔ：「疲れてきたよぉ～」
ｓｔ：「お菓子ありますよ。食べます？」
ｙｔ：「食べゆ～♪」
|
「プロペラ帽」はハッカーの印、トリッキーなコードを書いた人はこれをかぶらないといけない．
|
タスクはこんな感じ。終わったものは消し込む。
「やったあー！」
「第３イテレーションまで終わったぞお。」＼(^o^)／
「最近、慣れてきて[スイスイ]って感じ！」\(^-^)\
|
| 感想（アンケート結果より抜粋） |
***********************************************************
■ xpプラクティスの評価(5段階 - 0=無効, 5=有効)
***********************************************************
| プラクティス名 | 5段階評価 |
| 計画ゲーム（タスク挙げ、サインアップ、見積） | ***3.4 |
| シンプルデザイン（設計を固定せず、随時変更） | ***2.6 |
| ペアプログラミング | ****4.0 |
| テスティング（ユニットテスト） | ****4.2 |
| テスティング（受け入れテスト） | ***2.6 |
| リファクタリング | *****4.7 |
| コードの共同所有 | ****4.0 |
| 週40時間 | ****4.0 |
| オンサイト顧客 | ******4.5 |
| コーディング標準 | ****4.0 |
***********************************************************
■ 良かった点
***********************************************************
- 毎朝、全員参加して各人の作業確認ができた。(stand-up meeting)
- 全員が意見を出してイテレーションができた。
- 達成感が得られ易かった。
- コミュニケーションがとれて和気あいあいとした雰囲気だった。
- 楽しく仕事ができた。
***********************************************************
■ 改善すべき点
***********************************************************
- １イテレーション＝１週間としたが期間が短かった。
- バランス良く全体に関われるようなタスク分担をすべきだった。
- もっとコミニュケーションを取るべきだった。
- ペア相手に頼り過ぎだった。
【戻る】
|
| 最後に |
マネジャとコーチからの感想です．
■(sh: マネジャ)
本プロジェクトで初めてｘｐを体験する人ばかりでしたが、
コーチの指導の下でペアプログラミングやテストファーストなど．
多くの手法を楽しく学べたことが非常に良かった
と思います。今回でｘｐのすべてを実践した訳ではないですが、今後のプロジェクトに
役立つことは間違いないと確信しました。
■(kh: コーチ/トラッカ)
今回のプロジェクトで気付いたことを，ポイント毎にまとめてみま
す．
【戻る】
|
以下，各イテレーションで出た生の感想，生のアンケートデータなどです．
|
| 付録ａ．イテレーションの考察 |
第１イテレーション
- ant/cvs
- cvsで，フォルダの追加/削除は鬼門だ．
プロジェクトが少し混乱した．(sh)
- テストまで含めた build.xml がまだできていない．(sh)
- model と servlet で build ターゲットを分けたが，
その御蔭でservlet をコンパイルすると*必ず* model がコンパイルされてしまう．
よい方法は? (sh)
- 見積り意識しなかった．
次のイテレーションでは見積りの感覚を掴みたい．(kk) (新入社員)
- 開発
- ペアプロは緊張感が持続してよい．(yt)
- タスクが完成した，と言えるのはいつなのかがはっきりしない．(yt)
- ・ペアプロは楽しい．リファクタリングの仕方など勉強になった．(st)
- テストコードを書くのは難しい．次からはうまくできる．(st)
- servlet のテストは難しい．今回，cuctas は不採用．httpunit
の受け入れテストで併用．その代わり，servlet/jsp にはロジック
は持ち込まず，model に追い出す．(kh)
- 全体的にテスト不十分．日付や年齢の境界値とかやっていない．
- テストのドキュメント書かないの?
デフォルト xp では書かないが，ユーザが欲しいといえば，
それをタスクとして追加．
- ちょっと，進捗が遅い気がする．入社1-3年が主体なのでしょう
がないか．．．それともペアプロの負荷?
- 受け入れテスト
- 受け入れテストを httpunit で作ったが，結局動くコードを見なが
らテストを作ってしまった．(kh)
- 初期テストデータは，ファイルで格納してそれに依存したテスト
になってしまったが，本来ならテストの中で初期テストデータも作るべき．(ay)
- 受け入れテストの初期データ，どうしよう．．．
「登録」ストーリーが出来たら，検索と対にしよう．
- 受け入れテストは難しい．見た目をコードでチェックするのは難しいし，
レイアウトデザインの変更でテストが変更になるのは苦しい．
あまりレイアウトに敏感でないテストがよい．(ay)
|
第２イテレーション
|
第３イテレーション
|
第４イテレーション
- 今回も早くタスクが終ってしまった．
- 実質作業工数は，4日 x 3名 = 12 人日．
見積は 4.5 理想人日の作業なので，負荷係数は，2.7
見積比で効率が上がっている．
- 全 jsp の先頭にログインチェックを入れた．
include を始めて使って見る．
- java.utils.collections のソートを駆使する．
【戻る】
|
| 付録ｂ．アンケート集計結果 |
プロジェクトメンバ紹介
----------------------
(1) 氏名
(2) 役割
(3) 開発経験（自己紹介）
----------------------
(1) yamamoto（以下 ay）
(2) 顧客
(3) プログラムを書き始めたのは高校1年から、学校にあったtk-80bsを使い
tinybasicで遊んでました。記憶デバイスは300bpsのオーディオテープしか
なくて大変でした。ですから開発経験は２０年ってことになります。
これまで手を出した言語は、basic、アセンブラ、cobol、fortran、c(c++)、
lisp、prolog、pascal、javaと一通りやってきました。使い込んだ言語と
しては basic、アセンブラ、cobol、c(c++)、pascalですが、最近はcobolと
pascal(delphi)が中心です。
javaも興味があって少し手を出しかけたのですが、時間が無くて開発経験と
呼べるようなものはありませんでした。今回少しいじってみて、ある程度判っ
てきたように思います。文法がｃと大差ないので、java特有のコツがもう少し
判れば何とかなりそうです。
(1) 花田臣二（以下 sh）
(2) マネジャ、プログラマ
(3) ｃｏｂｏｌ開発：１７年
ｊａｖａ開発 ：基礎教育程度の知識
(1) 平鍋健児（以下 kh）
(2) コーチ，トラッカ
(3) c, c++, java, pascal など一通りの言語経験あり．
プロジェクト管理，オブジェクト指向設計，アーキテクト，コンサ
ルティングなど．
(1) 中谷（以下 yn）
(2) プログラマ
(3) 高校の時、プログラム電卓でゲームを作ったのが最初。
以後、約20年間で basic, c, java, c++ 等を経験。
主にos(unix), cad, caseツールの開発に従事。
(1) yt
(2) プログラマ
(3) 入社 3年目。javaでの開発はもうすぐ 1年。
サーブレットや jsp にも慣れてきて、
java“らしい”プログラミングがやっと分かりはじめたところ。
(1) st
(2) プログラマ
(3) 開発経験1年、java歴半年の初心者プログラマです。やっとjavaでの
プログラミングに慣れてきたかんじですが、設計する力がまだ
全然ないなって感じてます。
(1) kk
(2) プログラマ
(3) なし。言語教育で、初めてc、javaの言語を学びました。
|
mpilotプロジェクトで、もっとも苦労したと思う点はなんですか?
- テストを書くのがしんどかった。(ay)
- ｊａｖａ言語（基礎知識のみなので、model,clone,list,sort...etc）(sh)
- エディタ（meadow)が不慣れなので大変に苦労した。(今だにうまく使えない！）(sh)
- ネーミングが難しい。（英語力の問題か？）(sh)
- 朝のミーティングが長くなりがち(→スタンドアップにすべきだった)．(kh)
- 以下について，ある程度初期デザインした方が，全体効率はよかったかも．
- セッションの管理についての指針．セッションローカルとなる
変数名やクラスによる構造化の指針．（グローバル変数と同等なので）
- データベースレコード
- sybase(dbms)のインストールに、ちょっとしたコツが必要だったこと。(yn)
- 修正がこまめに入ったこと。
以前のプロジェクトでは、dbの関係上、最初に慎重な設計をして、それでも変
更になった場合には、できるだけ少量で済む修正を入れていた。今回は、修正
に対し「かかってこい」の態度だったので、初期にしておくべき考慮をほとん
どしなかったと思う。(yt)
- ブラウザの「戻る」ボタンで画面遷移することによって、
2度登録できてしまったこと。 結局どうにもできなかった。
- ペアを組む相手に声をかけるのが難しかった。(kk)
|
xpプラクティスを実践してみて、どう思いましたか?
● 5段階評価の平均値
| プラクティス名 |
評価 |
| 計画ゲーム（タスク挙げ、サインアップ、見積） |
3.4 |
| シンプルデザイン（設計を固定せず、随時変更） |
2.6 |
| ペアプログラミング |
4.0 |
| テスティング（ユニットテスト） |
4.2 |
| テスティング（受け入れテスト） |
2.6 |
| リファクタリング |
4.7 |
| コードの共同所有権 |
4.0 |
| 週40時間 |
4.0 |
| オンサイト顧客 |
4.5 |
| コーディング標準 |
4.0 |
● 各プラクティスに関する感想・コメント
|
◆ 計画ゲーム（タスク挙げ、サインアップ、見積）
- 核となるメンバで行った方が良いかもしれない。（タスク挙げ、見積など）(sh)
- 司会者の技量となれが必要．(kh)
- サインアップをすることで，やる気がでる．(kh)
- 見積もりは2回目からかなり自信がでる．(kh)
- ついつい慣れたタスクばかり選んでしまった。もっとバランスよくサインアップす
べきだった。(yt)
- 自分がどの程度の時間でできるのかがつかめず、タスクを率先して選ぶことができ
なかった。(kk)
◆ シンプルデザイン（設計を固定せず、随時変更）
- シンプルさの基準が解らない。(sh)
- 自分が使っている既存のコードが頻繁に変更されると戸惑う。（コミュニケーショ
ン不足の問題か？）(sh)
- 手戻りが多過ぎ．(kh)
- 将来、必ず必要になる機能（例: dbアクセス機能）でも後で追加した方がよいのだ
ろうか?(yn)
- 最初はちゃんと設計した方がよい。（モデル間の参照方向が2イテレーションめに変
更され、作業が増えてしまった。）(yt)
◆ ペアプログラミング
- （自分の役割は顧客だが）やってみたかった。(ay)
- 一方が主導権を持ってしまう傾向がある。(sh)
- 一人でやるより疲れる。（説明しながらパンチしている。）(sh)
- 見ていると違うことを考えてしまうことがある。（集中力が薄れる？）(sh)
- ずっとペアプロするのは難しい。調査時や考えをまとめるときはプレッシャーにな
る。(sh・st)
- 教育的効果が高い．(kh)
- ジュニアが指摘するミスとシニアが指摘するミスの数は変わらない．(kh)
- 楽しい．(kh・yn)
- 最初は面倒と思っていたが、実際にやってみて良さが分かった。コンパイルしなく
ても相棒がエラーを見つけてくれるのがよい。
コンパイルエラーより優しいし音声だし。(yn)
- 勉強になる。(yt)
- 変数名の付け方が丁寧だった。(yt)
- 緊張した。(st)
- リファクタリングなど勉強になることがいっぱいあったが、ずっとペアで
プログラミングしていると、たまにはひとりでやりたいと思うこともあった。(st)
- ほとんどが、見ているだけの状態であったが、とても勉強になった。（特
にエディタの使い方）(kk)
◆ テスティング（ユニットテスト）
- モデルでは十分に確認できている。サーブレットでは現状のままでは不十分。(sh)
- これを全クラスに用意できるとよかった．(kh)
- サーブレット/jsp のテストは難しい．モデルにロジックを逃がしたり、
doget()/dopost()以外のメソッドに処理を出すなどの工夫が必要．(kh)
- 楽しい．(kh)
- システムが大きくなると、テストへの修正だけで負担がかかるように思う。(yt)
- 実装してすぐテストをすると、デバッグを早くできてよい。(st)
◆ テスティング（受け入れテスト）
- 受け入れテストを顧客が作るというのは問題がありそうに思う。(ay)
- なんで、受け入れテストはペアプロじゃないの？(ay)
- テスト内容も解っていないので、評価できないのが正直な所です。(sh)
- 顧客が全部用意するのは大変．非常に労力がいる(kh)
- httpunit は非常によい．(kh)
- ついつい手でテストして終りにしてしまう．
再現可能なテストコードとして残すのは手間がかかる．(kh)
◆ リファクタリング
- 実は、結構好きなんですリファクタリング。
自分の仕事でリファクタリングやりすぎて時間が足りなくなったりするんで、
どこで歯止めを掛けるかが問題かも。ただし、リファクタリングの前提としては、
しっかりとテストが書かれていることが前提として必要なのでは？(ay)
- システム規模やリファクタリングに当てられる時間によっては、
なかなか難しいと思う。(sh)
- ペアプロをしながら，リファクタリングをジュニアに伝授することが
できてよかった．(kh)
- 大規模リファクタリングは，全体を一旦フリーズして行った．
(定時後に一名がやってしまう)
- 例: ユーティリティクラスの名前の変更．
これはよかっただろうか．現実にはこれがいいと思う．(kh)
- “この部分がリファクタリングできる”と思い付いた時が快感。
でも、リファクタリング後に“前の方がよかった”と気付くこともあるので、
週40時間（実際に取り掛かる前に時間を置ける）と cvsの利用（前の版に戻せる）
は不可欠。
- コードがすっきりして気持ちがいい。(st)
- コードが短くなっていく様子を実際にみることができ、リファクタリング
のすごさが実感できた。(kk)
◆ コードの共同所有権
- コミュニケーションをしっかりとらないと難しい。(sh)
- 結果的に，ほぼ守れた．(kh)
- 特別な意図があって書いたコードには、ちゃんとしたコメントを書かなく
ては危険だと思った。（つぶされてしまう可能性がある。）(yt)
- cvsで格納の際にうまく処理できず、ファイルを壊してしまうことがあった。(kk)
◆ 週40時間
◆ オンサイト顧客
◆ コーディング標準
- ペアのどちらかがコーディング標準を熟知している場合しか、
ちゃんと機能していなかった。(yt)
|
|
作業スペースとして、よかった点・改善すべき点があれば教えて下さい。
- 専用のホワイトボードがあるとよかった。(yt・kk)
|
うまく書けたと思うコードはどの部分ですか?
また、うまくリファクタリングができた箇所などもあれば教えて下さい。
- acceptanceのhumanlist classやmpilottest classで書いたコードは面白かった。
特にmpilottest classのcellstringhasは最初書いたコードでは、
行と列がテーブルに含まれるか調べてからセルをテストしていたので
コードが単調で汚く、非効率だったのがうまくリファクタリングできたと自分では思っています。(ay)
リファクタリング前
boolean cellstringhas(webtable wt, int row, int col, string keystr) {
if (row >= 0 && row < wt.getrowcount()
&& col >= 0 && col < wt.getcolumncount())
return stringhas(wt.getcellastext(row, col), keystr);
return false;
}
リファクタリング後
boolean cellstringhas(webtable wt, int row, int col, string keystr) {
try {
return stringhas(wt.getcellastext(row, col), keystr);
} catch(indexoutofboundsexception ex) {
return false;
}
}
- mpilotmodel.issame()メソッド：ポリモーフィズムを利用できた。(yt)
|
どんなところを改善した方がよいと思いますか?
● xpに関して
- 受け入れテストのことを考えると、htmlではなくxmlとxslで
画面を作るように持っていきたいですね。
今のままでは、画面デザインを変えるたびに受け入れテストを画面に合わせなければ
ならないので(ay)
- 少し大きな単位で分担した方が、担当者間の独立性があるのではと思う。
（１イテレーション＝２週間程度として、その間はペアを変えないで実施した
方が良いかもしれない。）(sh)
- 自分としては、もっとコミュニケーションをとるべきだった。(kk)
- ペアの相手に頼りすぎてしまった。(kk)
● mpilotプロジェクトに関して
- modelstoreの実装が多すぎるように思う。(sh)
- 日付の入力で"/"不要（例: 20010727）とした方がよいと思う。(yn)
- build.xmlにjavadoc機能(ant javadoc)を追加した方がよいと思う。(yn)
- javadocのコメントを、しっかり書いた方がよいと思う。(yn)
- meadowでファイルの最後に空行を入れない設定をしていない人がいるようなので
設定した方がよいと思う。(yn)
- バランスよく全体に関われるようなタスク分担をすべきだった。(yt)
|
感動した出来事やコードがあれば教えて下さい。
また、「今回勉強になった」と思うことがあれば教えて下さい。
- 感動したというか勉強になったというか...
インターフェースを関数の中で定義してパラメータとして渡せるって事が判って、
面白かったですね。
ｃやpascalでは引数として関数（のポインタ）を渡したりはしますが、
ここまでの柔軟性はないと思います(ay)
acceptanceのhumanlist classより
public interface humanpredicate {
public boolean istrue( human hu );
}
上記のインターフェースを引数としてループ内で使用する
public int indexwith(int index, humanpredicate predicate){
~~~~~~~~~~~~~~~~~~~~~~~~
for(; index < size(); ++index)
if ( predicate.istrue( (human)get(index) ) )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
return index;
return -1;
}
public humanlist getlistwith(humanpredicate predicate){
~~~~~~~~~~~~~~~~~~~~~~~~
humanlist hulist = new humanlist();
for(int i = 0; (i = indexwith(i, predicate)) != -1; ++i)
~~~~~~~~~~~~~~~~~~~~~~~
hulist.add( getof(i) );
return hulist;
}
public humanlist getlistwithkana(final string kana) {
return getlistwith( ~~~~~~~~~~~~~~~~~
new humanpredicate() {
public boolean istrue(human hu) {
return (hu.kana.indexof(kana) == 0);
} ~~~~ここに注目
}
);
}
何に感動したか判ってもらえます？
indexwithとgetlistwithは簡単に使い回せるってところがミソですね
そして、getlistwithkanaのようにfinal宣言されたパラメータを条件
判断に利用できてしまう所も大きなポイントです。
- ユニットテストを理解できたこと。(sh)
- ａｎｔによる自動化ができたこと。(sh)
- ｃｖｓによるマスタ管理がよかった。(sh)
- 二人組が，テストをパスさせて手をパチパチ叩いている姿．(kh)
- コーチがお菓子を支給していたが，
しばらくすると全員がお菓子を持ち寄るようになったこと．(kh)
- ツールの利用方法などが，ペアプロを通してスムーズかつ高速に伝搬すること．(kh)
- タスクやキーとなる画面遷移を模造紙に書いて壁にはったこと．(kh)
- wincvsの使い勝手がよかった（例: 変更したファイルの色が変わる）こと(yn)
- ユニットテストでバーが緑になったこと。(yt)
- リファクタリングのし方が分かった。(yt)
- やっとポリモーフィズムの便利さがわかった。(yt)
- interface を new して無名クラスのコンストラクタを作ることができるということがとても勉強になった。(st)
collections.sort(persons, new comparator(){
^^^^^^^^^^^^^^^^
public int compare(object o1, object o2){
}
});
- また、リファクタリングが勉強になった。これから積極的にリファクタリングすることを心がけたい。(st)
- リファクタリングによるコードの短縮。(kk)
- junitによるテスト。(kk)
|
どんなところに心残りがありますか?
- flash作る暇が無かった(ay)
- ａｎｔをもっと活用したい。（javadocなど）(sh)
- servlet/jsp のテスティング．(kh)
- 受け入れテストの数が足りない．(kh)
- 継続的インテグレーションができなかったのは惜しい．統合用マ
シンで常にビルドとテストを走らせなければならなかった．(kh)
- インテグレーションのシリアライズのために，統合マシンを用意
することをしなかった．cvs でそれぞれ単体テスト終了でコミット
してしまった．(kh)
- 結果的に 40 時間を達成できたのは，本当の顧客や本当の契約に
よるプレッシャーが無かったからかもしれない、というわだかまりを感じる．(kh)
- dbアクセス機能を実装する前にプロジェクト異動となったこと。(yn)
- ダイエット中で、お菓子が食べれなかったこと。(yn)
- ネーミングルール・コーディングルールがちゃんと適用できなかった。(yt)
- セッションにログインフラグを立てるのでなく、ログイン名を保持させればよかった。(yt)
- 新人さんにもっとコードの意味をこまかく説明すればよかった。(yt)
- 計画ゲームのタスク挙げにあまり参加できなかった。 設計する力をつけたい。(st)
- タスクを振り分けるときに、自分から全く発言できなかったこと。(kk)
- わからないところ、動きをもっと質問するべきだった。(kk)
- 全体の動きを把握できていなかった。(kk)
|
なにか感想があれば、教えて下さい。
- javaって結構面白かったです。いままで、あまり良い印象が無かったんですが。
今度はプログラマーとして参加してみたいですね。(ay)
- 毎朝の会議は、全員が参加して各人の作業を確認することができて良かった。(sh)
- 全員が意見を出し合って完成できたことが良かった。(sh)
- 終了の飲み会しなきゃね．(kh)
- プロジェクト途中で異動となり心残りですが、是非よいものを作ってください。(yn)
- 達成感が得られやすいプロジェクトだった。
テストのおかげもあるし、結果が目に見えやすい開発でもあったからだと思う。(yt)
- コミュニケーションがきちんと取れて、和気あいあいとした雰囲気だったので
楽しく仕事ができてよかった。(st)
- 今回は、隣で見ているだけでも、精一杯でした。(kk)
fin
|
|
|
|
