Index: [Article Count Order] [Thread]

Date:  Sun, 4 Jun 2000 17:17:39 +0900
From:  Yutaka Kamite <y-kamite@....jp>
Subject:  [XP-jp:00482] XP Glossary 修正( #2 )
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <393A10472B0.CFAFY-KAMITE@....jp>
Posted:  Sun, 04 Jun 2000 17:16:07 +0900
X-Mail-Count: 00482

上手@データ通信システムです。

 (#2)佃さん、石橋さん、コメントありがとうございました。
(#1)吉田さん、ホソカワさん、コメントありがとうございました。

 修正(#2) をポストします。

用語集
Glossary

可能な限り、XPは広く受けいれられている語彙(vocabulary)を使う。XPの概
念が他の概念と著しく異なる場合は、その違いを新しい単語を使うことで、違い
を際立たせる。以下がXPの語彙のうち最も重要な単語である。

自動テスト Automated test
人が介在しないで動くテストケース。テストはそのシステムが確かに期待通りの
結果をはじきだすかをチェックする。

コーチ Coach
チームの中の、プロセス全般を観察し、チームの関心を問題を解決すること、改
良する機会に向けさせる役割。

コミットメントスケジュール Commitment schedule
リリース範囲と期日。コミットメントスケジュールは一度に一つのイテレーショ
ンについて練られ(refined)、再見積りとリカバリで修正される。

顧客 Customer
システムがどのようなストーリーを満たすべきかの選択、どのストーリーが先で
どのストーリーが後回しできるかの選択、ストーリーが正しく機能していること
を確かめるテストの定義、ができる役割を持つ者。


エンジニアリングタスク Engineering task
プログラマが知っているそのシステムが行わなければならない一つの事。タスク
は1〜3理想的プログラミング日で見積ることが出来ること。大半のタスクはス
トーリーカードから直接導かれる。

エントロピー Entropy
時間が経つとシステムがバグだらけになっていく傾向、変更コストが段々高くな
る。

探求 Exploration
全システムが出来そうなことについて、顧客が全般的に知識を共有する開発の局
面

機能テスト Functional test
顧客の視点から書かれたテスト

理想的プログラミング時間 Ideal programming time
見積手法の測定単位。自分に”気が散ることや災難が無かったら、この開発には
どれくらい時間がかかるか”と質問すると得られる答え。

イテレーション Iteration
1〜4週間の期間。最初に顧客がイテレーションで実装する機能を選択する。最
後に顧客が機能テストしイテレーションが成功したかどうかを判定する。

イテレーション計画 Iteration plan
一山のストーリーと一山のタスク。プログラマはタスク(に対する責任を)承認
し、それを見積もる。(その後積算して、全体のバランスをとる)

負荷係数 Load factor
理想的プログラミング時間とカレンダー(時間)の標準的な比率。通常2〜4。
(訳注:理想的プログラミング日が1日なら、カレンダー日で2〜4日かかる)

マネージャー Manager
チームの中で資源を割り当てる役割。

ペアプログラミング Pair programming
二人が一つのキーボード、一つのマウス、一つのモニターでプログラムするプロ
グラミング技術。XPでは通常、ペアは一日に何回か変わる。

パートナー Partner
あなたとペアプログラミングをしているもう一人の人。

プランニングゲーム Planning game
XPの計画プロセス。ビジネスはそのシステムが何をすべきか明記する。開発は
各機能(feature)についてどれだけコストがかかり、得られる予算は日/週/月で
どれだけかを明記する。

実運用 Production
#佃案、”運用”に”実”を追加
#訳の別案:本稼動、実働、実用
そのシステムを使って、顧客が実際に付加価値を生み出している発展の局面。

プログラマ Programmer
チームの中の、設計し、テストし、プログラムし、構築する役割。

リカバリ Recovery
見積の増加あるいはチームスピードの低下に対応し、そのリリースの範囲を減ら
すことでリリース完了日を守る計画行為。

再見積り Reestimation
そのリリースで残っている全てのストーリーをチームが再見積をする計画行為。

リファクタリング Refactoring
振る舞いは変えずに機能ではない品質ー単純性、柔軟性、理解性、性能ーを強化
する、システムに対する一つの変更。

リリース Release
まとまることでビジネス上の意味を持つストーリーの山。

ストーリー Story
顧客がそのシステムにやって欲しい一つの事。ストーリーは1〜5理想的プログ
ラミン週で見積もれること。ストーリーはテスト出来ること。
(訳注:通常、ストーリはタスクに分割して変換される)

システムメタファ System metaphor
顧客、プログラマ、マネージャーの誰もが、システムがどのように動くかをわか
る一つの(例え)話。
(訳注:メタファは、比喩、暗喩、類似したもの、と訳されることが多い)

チームスピード Team speed
与えられたある量の時間の中で、チームが実際に開発に使える理想的なプログラ
ミング週の数。

テストケース Test case
システムに対する刺激(stimuli)と応答(response)の自動化されたセット。各テ
ストはシステムに入った時のシステムの状態を保って終了するので、互いに独立
に走らせることが出来る。

トラッカー Tracker
チームにおいて進捗を数字で計測する役割

単体テスト Unit test
プログラマの観点から書かれたテスト

(以上)