ホソカワです。
私のコメントです。
on 2000/05/25 11:44 AM, Yutaka Kamite at y-kamite@....jp wrote:
> 上手＠データ通信システムです。
> 遅ればせながら、Glossaryのまとめです。チェックをお願いします。
> 解釈が怪しいところには原文も併記しました。
> 皆さんの衆知をお貸し下さい。
>
> 用語集
> Glossary
>
> 可能な限り、ＸＰは広く受けいれられている語彙(vocabulary)を使う。ＸＰの概
> 念が他の概念と著しく異なる場合は、その違いを新しい単語を使うことで、違い
> を際立たせる。以下がＸＰの語彙のうち最も重要な単語である。
>
> 自動化テスト Automated test
> 人が介在しないで動くテストケース。テストはそのシステムが期待値を算出する
> ことを確実にするためにチェックする。
>
> コーチ Coach
> チームの中の、プロセス全般を観察し、チームの関心(attention)を問題を解決
> すること、改良する機会(opportunities)に向けさせる役割
>
> コミットメントスケジュール Commitment schedule
> A release and a date.
> ？？一つのリリースとその完了予定日。
> コミットメントスケジュールは一度に一つのイテレーションについて練られ
> (refined)、再見積りとリカバリで修正される。
>
Customerが抜けています。
顧客 Customer
システムがどのようなストーリーを満たすべきかの選択、どのストーリーが先でどの
ストーリーが後回しできるかの選択、ストーリーが正しく機能していることを確かめ
るテストの定義、ができる役割を持つ者。
> エンジニアリングタスク Engineering task
> プログラマが知っているそのシステムが行わなければならない一つの事。タスク
> は１〜３理想的プログラミング日で見積ることが出来ること。大半のタスクはス
> トーリーカードから直接導かれる。
>
> エントロピー Entropy
> 時間が経つとシステムが大きくなっていく傾向、変更コストが段々高くなる。
>
「to get buggier」は、「虫だらけになる」ですので、「時間が経つとシステムがバ
グだらけになっていく傾向」がいいと思います。
> ？？探求 Exploration
> The phase of development when the customer communicates generally what
> all the system could do.
> 全システムが出来そうなことについて、全体的に顧客が知識を共有する開発の局
> 面
>
> 機能テスト Functional test
> 顧客のプログラマの視点(perspective)から書かれたテスト
>
顧客の「プログラマ」と、明示的に書いてありませんので、ない方がいいと思います。
顧客は必ずプログラマである必要はないと思います。
> 理想的プログラミング時間 Ideal programming time
> The measure of an estimation tactic where you ask yourself,"How long
> would this take without distractions and disasters?"
> 見積手法の測定単位。自分に”大混乱や災害が無かったら、この開発にはどれく
> らい時間がかかるか”と質問すると得られる答え。
>
distraction は、「大混乱」より「気が散る事」がいいと思います。
> イテレーション Iteration
> １〜４週間の期間。最初に顧客がイテレーションで実装する機能を選択する。最
> 後に顧客が機能テストしイテレーションが成功したかどうかを判定する。
>
> イテレーション計画 Iteration plan
> 一束のストーリーと一束のタスク。プログラマはタスクを登録し(sigh up)、そ
> れを見積もる。
>
好みの問題でしょうが、私は、pileは、「一束」より「一山」がいいと思います。ス
トーリーカードが山積みされている光景をイメージしています。
…
--
Kaoru Hosokawa
khosokawa@....com