ホソカワです。
on 2000/03/13 10:27 AM, Yutaka Kamite at y-kamite@....jp wrote:
>> ・システムの腐食ー一定レベルの品質を確保するために変更がある度に包括的なテス
>> トを行います。常にソフトウェアは最良の状態に保たれています。cruft [私の辞書
>> に載っていませんでした。]は、たまりません。
>>
>
>
> http://www.infoseek.co.jp/
> で検索したところ、
> http://www.denken.or.jp/local/misc/JARGON/body-c/cruft.html
> http://www.denken.or.jp/local/misc/JARGON/body-c/cruft.html
>
> 1. n. An unpleasant substance. The dust that gathers under your bed is
> cruft; the TMRC Dictionary correctly noted that attacking it with a broom
> only produces more.
>
> 2. n. The results of shoddy construction.
> な例がでていましたので、いわゆるデグレードのことでは無いでしょうか。
> 結構便利そうなページですね。
調べていただいて有り難うございます。cruftとは、「綿ぼこり」見たいなものでしょ
うか？「Cruft is not allowed to accumulate.」は、「デグレードの要因が溜まる
ような事は許されません。」といった感じでしょうか？
解説をアップデートしました。それから解説も宜しくお願いします。
---
Chapter 1 Risk: The Basic Problem
==============================
ソフトウェア開発の基本的な問題は失敗する危険性（risk）があると言う事です。例
えば、このようなリスクがあります。
・スケジュールの遅延ー納期日にユーザーに「後、６ヶ月かかります。」と伝えるこ
と。
・プロジェクトの中止ースケジュールの遅延が重なり、製品が出荷出来ないこと。
・システムの腐食ー出荷したが、数年後には変更のコストや障害率が高すぎて、捨て
ざる得なくなること。
・障害率ー出荷したが、バグが多すぎて使われなくなること。
・ビジネスの勘違いー出荷したが、もともと解決しようとしていた問題を解決してい
ないこと。
・ビジネスの変化ー出荷したが、解決しようとしていた問題が６ヶ月前に違うもっと
緊急な問題に変わっていたこと。
・多数の的はずれな機能ーもしかすると使ってもらえる機能、もちろん作るのは楽し
かった機能が、ユーザーにとっては無益だったこと。
・スタッフの転職率ー２年後、有能なプログラマたちがシステムに嫌気がさし、転職
すること。
XPは、こう言ったリスクを以下のように対処しています。
・スケジュールの遅延ーXPのリリースサイクルは短いので（長くても数カ月なので）
遅れの影響度は限定されています。また、XPでは重要度の高い機能から着手するので、
スケジュールに間に合わない機能は（必然的に）重要度の低い機能になります。
・プロジェクトの中止ーXPは、ユーザーにもっとも有益で、かつ細小構成のリリース
を選んでもらいます。構成が細小なので出荷前に間違いが起きる可能性が減りますし、
もっとも有益なものを選んでいるので、システムの価値は最大です。
・システムの腐食ー一定レベルの品質を確保するために変更がある度に包括的なテス
トを行います。常にソフトウェアは最良の状態に保たれています。デグレードの要因
が溜まるような事は許されません。
・障害率ーソフトウェアはプログラマの観点（関数単位のテスト）とユーザーの観点
（機能単位のテスト）からテストされています。[ので、障害率を押さえることがで
きます。]
・ビジネスの勘違いーユーザーは開発チームの一員です。プロジェクトの仕様は頻繁
に更新されているので、ユーザーと開発チームの学んだことはすぐに仕様に反映され
ます。
・ビジネスの変化ーXPは、短いリリースサイクルで開発を行っているので仕様変更が
あまり起きません。[開発期間が短いので変更を行う前にリリースが完成してしまう
ということ。] また、開発途中にユーザーは新しい機能をまだ実装されていない機能
と＊置き換える＊ことができます。
・多数の的はずれな機能ーXPでは、重要度の高い機能のみ扱います。
・スタッフの転職率ープログラマに、作業の見積もりと遂行に責任を持ってもらいま
す。見積もりの変更を行えるのはプログラマです。[チームリーダーでもマネージャー
でもありません。]ですから、無謀なスケジュールを押し付けられて、失望する可能
性が減ります。新しいメンバーは徐々に責任を増やされていき、他のメンバーの支援
を受けるような仕組みを取り入れています。
---
タイトル （ページ数）担当者
Foreword (2) パス！
Preface (8) ホソカワ
Section 1 The Problem
Chapter 1 Risk: The Basic Problem (4) ホソカワ
Chapter 2 A Development Episode (4) ホソカワ
Chapter 3 Economics of Software Development (4) ホソカワ
Chapter 4 Four Variables (6)
Chapter 5 Cost of Change (6)
Chapter 6 Learning to Drive (2)
Chapter 7 Four Values (8)
Chapter 8 Basic Principles (6)
Chapter 9 Back to Basics (8) 矢崎
Section 2 The Solution
Chapter 10 Quick Overview (10)
Chapter 11 How Could This Work? (8)
Chapter 12 Management Strategy (6)
Chapter 13 Facilities Strategy (4)
Chapter 14 Splitting Business and Technical Responsibility (4)
Chapter 15 Planning Game (12)
Chapter 16 Development Strategy (6)
Chapter 17 Design Strategy (12)
Chapter 18 Testing Strategy (6)
Section 3 Implementing XP
Chapter 19 Adopting XP (2)
Chapter 20 Retrofitting XP (6)
Chapter 21 Lifecycle of an Ideal XP Project (8)
Chapter 22 Roles for People (10)
Chapter 23 20-80 Rule (2)
Chapter 24 What Makes XP Hard (4)
Chapter 25 When You Shouldn't Try XP (4)
Chapter 26 XP at Work (6)
Chapter 27 Conclusion (2)
--
Kaoru Hosokawa
khosokawa@....com