ソフトウェア開発: 2007年9月アーカイブ
「ソフトウエア見積もり」－人月の暗黙知を解き明かす
Software Estimation:Demystifying the Black Art
Steve McConnell
田沢 恵、溝口 真理子 訳
久手堅 憲之 監修
日経BPソフトプレス(2006)
★★★★★
Don't reduce developer estimates
--they're probably too optimistic already.
McConnellの最新作。ソフトウェア関係者の必読書であると思います。さまざまな手法、考え方の集大成ですから、これ1冊読めば、見積もりは、ほぼ完璧です。勘と経験と度胸から決別する最初の1歩でしょう。米国の業界標準のデータも貴重です。これからの見積りが劇的に変わりそうです。
ポイント20：開発者の見積もりを削ってはいけない。なぜなら、既に十分楽観的すぎるからだ。
第1章 見積りとは
ポイント1：「見積り」「ターゲット」「コミットメント」はそれぞれ異なるものであると認識しよう。
ポイント2：見積りを求められたときは、実際に見積もりを行うのか、ターゲットの達成方法を尋ねられているのかを判断すること。
見積りにとって重要なことは。完璧なまでに正確であることより、有用な情報を提供することである。
第7章 数えて、計算して、判断する
ポイント30：できるときはいつでも、まず数えよう。数えられないときには、計算しよう。判断だけに頼るのは最後の手段だ。
第8章 補正と過去のデータ
ポイント36：「うちのチームは平均以下かどうか」という前提から議論するような政治的圧力のかかった見積りを避けるために、過去のデータを使用しよう。
ポイント37：見積りに使用する過去のデータを収集するときは、小さな規模で始め、自分が何を収集しているのか理解して、一貫性を持ってデータを収集しよう。
ポイント38：プロジェクトが終わったら、できるだけ早くプロジェクトの過去のデータを収集しよう。
ポイント41：できるだけプロジェクトのデータまたは過去のデータを使用して、見積もりを補正しよう。できれば業界平均データは避けよう。過去のデータを使用して補正すると、より正確な見積もりができるだけでなく、生産性に関する前提の不確実性から生じる見積りのばらつきを減らすことができる。
第9章 専門家の判断
ポイント43：タスクレベルの見積もりは、実際に作業に携わる者が見積りを作成しよう。
タスクレベルの見積もりを行うときは、長くても2日程度の工数のタスクにまで見積もりを分解する。それより大きいタスクだと、想定外の作業が隠れる場所が多すぎる。見積もりは4分の1日、2分の1日、丸1日といった粒度で行うとよい。
ポイント44：最良ケースと最悪ケースの見積もりを作成して、起こり得るすべての範囲の結果について考えるきっかけにしよう。
ポイント45：見積りのチェックリストを使用して、個々の見積もりを改善しよう。自分の個人的なチェックリストを開発して保持し、自分の見積もりの正確性を改善しよう。
ポイント46：実績を見積もりと比較して、時間とともに個々の見積もりを改善できるようにしよう。
第10章 分解して、また組み立てる
ポイント47：大きな見積もりを小さい部分に分解して、「大数の法則」の恩恵にあずかろう。プラスの誤差とマイナスの誤差は、ある程度まで互いに打ち消しあう。
ときどき、「忘れ去られた機能」という形で、目に見えない作業が隠れていることがある。「忘れ去られたタスク」という形で隠れていることもある。タスクを忘れないようにするには、活動基準WBSを使用するとよい。見積もり対象のプロジェクトと似たような過去のプロジェクトを比較して、大きいか小さいかを考える時の微調整にも役立つ。新しいプロジェクトと過去のプロジェクトをWBSのカテゴリごとに比較すると、どの部分が大きくてどの部分が小さいかを細かく評価できる。
ポイント49：タスクが10個以下の見積もりの場合、最良ケースと最悪ケースから意味のある総見積りを計算するには、簡単な標準偏差の公式を使用しよう。
ポイント51：個々のタスク見積りに使う標準偏差を得る時には、最良ケースから最悪ケースまでの範囲を6で割ってはならない。見積もりの範囲の正確性に応じて、除数を選択しよう。
ポイント52：期待ケースの見積もりを正確にしよう。個々の見積もりが正確ならば、そこから得た値は問題を起こさない。個々の見積もりが正確でなければ、正確に求める方法が見つかるまで、そこから得た値には多くの問題がある。
第11章 類推見積り
ポイント53：新しいプロジェクトを見積もるときは、過去の似たようなプロジェクトと比較して、できれば5つ以上の部分に分解して見積もろう。
見積りの焦点は、正確さに合わせるべきで、慎重な保守主義をとればよいというものではない。見積もりの焦点がいったん正確さから離れると、さまざまな原因から先入観が混入し、見積もりの価値を下げてしまう。不確実性に最もうまく対処するためには、見積もりから先入観を排除することだ。それと同時に、根底にある不確実性を正確に表現することも必要だ。
第12章 代替指標による見積り
ポイント59：Tシャツのサイズ分けを使用すると、プロジェクトが「不確実性のコーン」の広い部分にある間、非技術系のステークホルダーが要求機能を線引きして取捨選択するのに役立つ。
第13章 専門家グループによる判断
ポイント62：グループレビューを行うと、見積もりの正確さを改善できる。
ポイント63：プロジェクトの初期の見積もりをするとき、あるいは馴染みのないシステムを見積もるとき、またはプロジェクトそのものにさまざまな分野がかかわるときは、広域デルファイ法を使用しよう。
第14章 ソフトウェア見積もりツール
ポイント64：見積りツールを使用して、手作業で作成された見積もりが正しいかどうかチェックしよう。大規模なプロジェクトほど、市販の見積もりツールを活用すべきである。
ポイント65：ソフトウェア見積もりツールの出力結果を神の信託のように扱ってはならない。見積もりツールのアウトプットも、他の見積もりと同じように、正しさをチェックしよう。
第15章 複数の見積もりの使用
ポイント66：複数の見積もり技法を使用して、それらの結果が集中しているか分散しているかを調べよう。
ポイント67：異なる見積もり技法によって別々の結果が生じるときは、その結果が生じる原因を探してみよう。異なる技法から生じる結果の差が5%以内に集中するまで、再見積りしよう。
ポイント68：複数の見積もりが一致したのに、ビジネスターゲットが一致しなかった場合は、見積もりの方を信頼しよう。
第16章 うまくいく見積りのフロー
ポイント69：見積りのアウトプットについて議論してはいけない。アウトプットはそのまま受け入れよう。アウトプットを変更してよいのは、インプットに変更があったときか、または再計算した場合だけである。
ポイント70：まず、規模の見積もりに焦点を合わせよう。次に、工数、スケジュール、コスト、機能を、規模の見積もりから計算しよう。
ポイント72：プロジェクトの進行に従って、それほど正確でない見積もりアプローチから、より正確な見積もりアプローチへと移行しよう。
ポイント73：具体的な開発タスクを配分して割り当てる準備ができしだい、ボトムアップ見積りに切り替えよう。
ポイント74：デッドラインを達成できなくて再見積りするときには、プロジェクトの進行計画ではなく、実際の進行に基づいて、新しい見積もりを作成しよう。
ポイント75：プロジェクトの進行につれて見積り幅が狭くなるような方法で、見積もりを提示しよう。
ポイント76：プロジェクトのステークホルダーには、前もって再見積りの計画を伝えよう。
第17章 標準化された見積もり手順
ポイント79：プロジェクトの見積もりと見積もりプロセスをレビューしよう。それによって、見積もりの正確性が改善され、見積もりを作成するために必要な工数が最小化される。
第18章 規模の見積もりの課題
ポイント80：規模を見積もるために、コード行を使おう。ただし、簡単な指標が持つ一般的な制限と、コード行特有のハザード（危険性）を忘れてはいけない。
ポイント81：ファンクションポイントを数えて、プロジェクトの初期に正確な規模の見積もりを手に入れよう。
ポイント84：適正な見積もり技法を使えば、規模の見積もりは他の見積もりの基礎となる。構築中のシステムの規模は、単体として最も大きなコストドライバである。正確に規模を見積もるためには、複数の見積もり技法を使おう。
第19章 工数の見積りの課題
ポイント85：規模の見積りから工数の見積りを正確に換算するために、見積りのサイエンスに基づくソフトウェアツールを使おう。
ポイント86：業界平均の工数グラフを使って、「不確実性のコーン」の広い部分で、大まかな工数の見積りを手に入れよう。プロジェクトが大規模なほど、強力な見積もり技法へ投資する正当性が容易に証明されることを覚えておこう。
ポイント88：すべての見積り技法が等しい結果を出すとは限らない。見積り間の集中と分散を調べる場合は、もっとも正確な結果を作り出す技法の結果を重視しよう。
第20章 スケジュールの見積りの課題
ポイント90：過去のプロジェクトと非公式に比較する公式をつかって、小～大規模プロジェクトのスケジュールを早い時期に見積もろう。
ポイント93：スケジュールの見込値を25％以上短くしてはならない。すなわち、見積もりを不可能ゾーンに入れてはならない。
ポイント94：スケジュールを長くして、小さなチームでプロジェクトを実行して、コストを減らそう。
ポイント95：中規模の業務システムプロジェクト（35,000～10万LOC）では、チームの人数が7人を超えてはならない。
ポイント97：見積り間の集中や分散を調べる前に、過度に一般的な見積もり技法の結果をデータセットから取り除くこと。
第21章 計画パラメータの見積り
計画パラメータの見積りは、あくまでも見積りである。つまり、粒度を細かくしたターゲットの設定と、粒度を細かくした見積りとが強く相互作用しながら、何度も繰り返されるべきものである。この段階における見積りのゴールは、初期の計画が現実的であることを確かめることであり、そこから先は、見積もりよりも、計画とプロジェクトコントロールが優先するはずだ。
最終的に、開発者とテスト担当者の構成比は、見積もりよりも計画によって安定する。つまり、あなたが「そうなるだろう」と予測することよりも、「そうあるべきである」と思っていることによって決まる。
「信頼性を95%から99%に向上させたいなら、スケジュールの本体に25%を加えるべきである。」「信頼性を99%から99.9%に改善したいなら、スケジュールにもう25%を加えるべきである。」
ポイント102：バッファ計画の出発点として、顕在化したリスク（RE)の合計を使おう。プロジェクトの具体的なリスクの詳細を見直したうえで、REの合計よりも大きなバッファを計画すべきか、小さなバッファを計画すべきかを最終的に判断しよう。
事務サポートの工数として、ベースとなる見積もり工数に5～10%を加える。
ITサポート（ラボのセットアップ、新しいソフトウェアのインストールなど）の工数として、ベースとなる見積もり工数に2～4%を加える。
構成管理と構築のサポートには、ベースとなる見積もり工数に2～8%を加える。
月あたり1～4%の要求の増加を想定する。
新しい言語およびツールを使った初めての開発を行う場合は、精通した言語およびツールで同程度の開発を行う場合に比べて、20～40%の工数増加を想定する。
新しい環境で初めての開発を行う場合は、精通した環境で同程度の開発を行う場合に比べて、20～40%の工数増加を想定する。
第22章 見積りのプレゼンテーション
ポイント104：見積りに組み込まれた前提条件は、文書化して伝えよう。
ポイント106：ごくわずかな可能性しかないプロジェクトの見積りなら、プロジェクトのステークホルダーには提示しない。
第23章 政治、交渉、問題解決
ポイント112：コミットメントは交渉できるが、見積もりを交渉の対象にしてはならない。
ポイント114：見積りの議論を、「交渉」ではなく、「問題解決」としてとらえよう。プロジェクトのステークホルダーたちは、全員がテーブルの同じ側にいる。全員が勝つか、全員が負けるかどちらかだ。
ソフトウェア開発プロフェッショナル
著 スティーブ・マコネル
著 松原 友夫
著 山浦 恒央
出版社/レーベル 日経BP社
出版日 2005-01-20
★★★★☆
本書の基となった"AFTER THE GOLD RUSH"のINTRODUCTIONより。
テキサス州で１９３７年にはじめてプロフェッショナル・エンジニアの免許が作られたのは、ボイラーの爆発で３００人以上の学童が死亡した後であった。その当時、ボイラーの故障した部分は、機械であった。今日、その機能をつかさどるのはソフトウエアである。よいソフトウエアは、私たちの生活を大いに良いものにしうるが、悪いソフトウエアでは非常に悪くしうる。よいソフトウエアを作るのに必要なプラックティスは完全に確立され、すぐにでも利用することができる。しかし、平均的なプラックティスと、最良のプラックティスの間には、大きな隔たりがある。次の統計を考えてみよ。
・航空宇宙産業の企業のソフトウエア開発は、プロジェクトの３パーセントが予算を超過し、１００のうち、９７がスケジュールを守る。一般的なビジネスソフトウエア開発では、１００パーセントが予算を超過し、たったの1/4が、当初のスケジュールの２５％以内の遅れでリリースされる。
・米空軍のためにソフトウエアを開発した、あるチームは、1年のスケジュールと2百万ドルの予算をコミットしたが、そのプロジェクトの最も信頼できる入札条件は、2年のスケジュールと1千万ドルの予算であった。積極的なリスク管理と、しっかりした基本開発によって、そのチームは予定より1ヶ月速くプロジェクトを完成させた。そのソフトはユーザーを喜ばせ、1年後、稼動中にわずか２つの欠陥が発見されたのみであった。プロジェクト管理者は、次のように指摘した。すなわち、このプロジェクトは、何年も前から知られている手法を使った。が、実際にはそれらの手法はほとんど使われていないものである、と。対照的に、平均的なソフトウエアプロジェクトでは全く何のリスク管理もなされず、100パーセント以上、スケジュールを超過する。
・ある組織は、開発期間を短縮すると決定し、体系的なプロセス改善に焦点を当てた。6年に渡り、毎年平均23パーセントづつのスケジュール短縮を達成した。合計91パーセントの短縮である。ほとんどの組織では適切なプロセス改善プログラムを持っていない。最悪の組織では生産性は毎年悪くなっているように見える。
・ある組織は、高品質を達成するとコミットし、9年にわたって、リリース後の欠陥率を平均39パーセント削減した。累積では99パーセントの削減である。平均的な組織では、リリース後の欠陥率がどのくらいかも知らない。
コードコンプリート 第2版 下
著 スティーブ マコネル
原著 Steve McConnell
翻訳 クイープ
出版社/レーベル 日経BPソフトプレス
出版日 2005-03
★★★★☆
下巻では、品質、インスペクション、テスト、デバッグ、リファクタリング、コード・チューニング、統合、ツール、ソフトウェア職人気質について、豊富な実例とデータで解説されます。
百科事典的な内容ですが、より深く理解したい人向けに300以上の参考文献が参考になります。
中級以上のプログラマの方は下巻のみでも十分だと思います。
初版にあった、この言葉に止めを刺すと思っていた次の言葉は変っていました。
「一生懸命は余分な、不要な努力である。それは、何とかしようとしているが仕事が終わっていないことを示している。効率的なプログラミングにおけるもっとも重要な仕事は考えることであり、人間は考えているときは忙しそうに見えない。もし筆者が、いつも忙しそうにしているプログラマと仕事をすることになれば、筆者は彼がよいプログラマではないと思うだろう。なぜならば、彼は彼の最も価値あるツール、脳を使用していないからである。」
新版では、以下のようになっていました。
「ひときわ優れたパフォーマンスを達成するには、一生懸命働くことに加えて、賢く働く必要がある。プロジェクトのデバッグ作業が多いことは、人々が賢く働いていないことを示す危険信号である。大量のコードを1日で書き上げ、そのデバッグに2週間かけるとしたら、賢く働いているとはいえない。」
「ラピッド・デベロップメント」でも「賢く」働くことが強調されていましたが、そうするためのヒントをたくさん、本書から見つけることが出来るでしょう。
コードコンプリート 第2版 上
著 スティーブ マコネル
原著 Steve McConnell
翻訳 クイープ
出版社/レーベル 日経BPソフトプレス
出版日 2005-03
★★★★☆
1993年に出版されたMcConnellの最初の著作の第2版。
上巻はプログラミングの初級から中級者を対象に、主にコーディング規約について述べています。
旧版ではコーディング･サンプルは、Basic、C、Pascalでしたが、新版では、C++、VB、Javaになっています。
読みやすさに工夫が凝らしてあって、「キーポイント」「ハード･データ」「コーディング・ホラー」のマークがあります。
ベテランの方は、章末の「まとめ」、「キーポイント」「ハード・データ」を拾い読みすることでも十分価値はあると思います。
「コーディング・ホラー」は悪いコーディングの見本です。
正直言ってコーディングのサンプルは、単純な例で、量も少なく、あまり参考にはならないと思います。
その中で、特に、論文でしか読めない「ハード･データ」が貴重であると思います。
例えば、
エラーを修正するコストは、大規模なプロジェクトでは一般に、アーキテクチャーの作成時に検出された要求のエラーを修正するコストが、要求の策定時に検出されたエラーの3倍に及ぶことが示されている。コーディング時に検出された場合のコストは5～10倍、システムテストの段階では10倍、そしてリリース後は10～100倍に跳ね上がる。(Boehm and Turner 2004)
という具体的な数字が示されます。
しかし、中級者以上にとっては、下巻に本書の価値があります。下巻は是非目を通していただきたいです。
ソフトウェアテスト 293の鉄則
世界中のソフトウェア技術者の共感を呼んでいる、開発現場から生まれた切れ味鋭い金言集
日経BP社(2003)
ソフトウェアその他
Kaner,Bach,Pettichord
★★★★
私は、ソフトウェアの開発者としての立場から、効果的にデバッグできるHOWTO本のようなものを期待して本書を読みました。
内容はまったく違いました。本書はテスト技術者によるテスト技術者のための本です。
本書でテストに対してのイメージが変りました。
今までは、最初に作るテスト項目と手順に従って行う、機械的な作業だという認識だったのですが、テストとはバグを検出することを目的とした創造的な活動であり、あるテスト結果によって、次に何をするかは、テスターの創造力に任されます。
具体的なデバッグのノウハウはほとんどありませんが、筆者たちが長い経験で得た293の経験則です。
ちなみに「鉄則」というのはLessonの訳だと思うのですが、意味が違うのではないでしょうか？
内容は非常に多岐にわたり、テスト技法、バグの報告などから自動化、ドキュメント、SWEBOK批判、キャリアの積み方、転職の仕方まで幅広いです。
対象はある程度大きな組織でテスト部門が独立しているところのテスターあるいはテスト責任者といったところでしょうか？
しかし、SOHOの私が読んでも損はなかったと感じています。読む人の立場によって、また別の発見があると思います。
最初に抽象的な説明がありますが、それにめげずに、５０ページは我慢して読むことをお勧めします。
共感した部分は
「著者たちは”ベストプラクティス”というものを信頼しない。理由は、最適な手法は状況に応じて異なると信じているからだ。ベストプラクティスの名を冠して売り出されている多くのものが、本来ふさわしくないところに無批判で適用されている、その状況を著者たちは憂いているくらいだ。」
「鉄則００５ 重大なバグを素早く見つけよう」
「鉄則０２１ 技術的、創造的、批判的、実践的な思考が優れたテストのカギ」
「鉄則０４０ 騙されやすいと自覚することが騙されない秘訣」
「鉄則１０８ 手動テストと自動テストを同格に扱うな」
「鉄則１４５ IEEE ８２９ 標準規格も使い方次第」
「鉄則１８５ 『十分なテスト』とは『正しい状況判断を下すのに十分な情報を得られること』である」
「テスト作業は、計画どおりに実行していく作業というよりも、むしろアイデアを生み出す活動である。」
「鉄則１９９ バグ総数によるプロジェクト進捗測定はするな」
「鉄則２０１ 進捗報告にバランススコアカードを適用せよ」
「鉄則２８０ テストケースの項目数からは何も分からない」
「鉄則２８６ 『どうすればより良いテストができるか』を常に問い続けよ」
「異なるタイプの欠陥は異なるタイプのテストによって見つかる。テストは挑戦的であるべきであり、できる限りプログラムが安定するように、あらゆるリスクに着目して行うべきである。」
「リファクタリング」
プログラミングの体質改善テクニック
ピアソン･エデュケーション(2000)
ソフトウェア設計
マーチン・ファウラー
★★★★☆
原書の副題は「既存のコードのデザインを改善する」というものです。
リファクタリングの定義は、「外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること」です。
多くの手法のカタログ的な構成になっていて、各手法は以下のような構成です。
(1)まず概要が簡単なコードの例やクラス図を使って説明されます。
(2)「動機」：なぜこのコードはリファクタリングされなければいけないのかが説明されます。ある種のアンチパターンのようなものです。
(3)「手順」：リファクタリング手順が詳細に示されます。少し修正して、少しテストというXPの見本のような手順がくどいほど繰り返されます。
(4)「例」：実際のコードの例が示されます。
デザインパターンもよく参照されますし、各手法も相互に関連していて、Javaの中級～上級者向けの本だと思います。
得る所が大きいのは、まず、Javaで、こうコーディングしてはいけない、というアンチパターンと、それをリファクタリングした結果の、
こうあるべきだという常識が、コードのサンプルから学べるところです。その意味ではJavaのプログラム作法的な本でもあります。
読み方としては、プログラム作法の勉強のために精読するもよし、どんな手法があるのか、ざっと眺めた上で、リファクタリングが必要になったときに、必要な部分を精読するのもよいと思います。
「リファクタリングはなぜ有効か---Kent Beck
今できることを作り込めばそれで終わりと考えているのであれば、長くプログラマを続けていくことはできないでしょう。
今日はできたからといって、明日には通用しないかもしれないそのやり方を通せば、いつかは敗者となってしまいます。
重要なのは、今の時点で何が必要かが把握できても、明日については何もわからないということです。
多分こうだろうと推測しても、想像もしなかったことが起こるかもしれません。
今日については十分把握できますが、明日については不十分なままです。
しかし、今日のためにしか仕事をしないとすれば、やがて明日には何もできないことになるでしょう。
リファクタリングは、この苦境から抜け出すための手段です。
昨日の決定が、今日には意味を持たなくなったと気づいたならば、過去の決定を変更してしまえばいいのです。
そうすれば今日の仕事ができるようになります。
明日には、今日の理解が多少未熟だったと思うかもしれません。だったらまた変更すればいいのです。」
実際に中規模のリファクタリングをやってみた感想としては、リファクタリングとして、特別に作業を行うのではなく、
普段のプログラミングの一部として、少しづつ行うのが効果的であると思います。
ファウラーさんの本にも書いてあるのですが、大きなリファクタリングは、小さなリファクタリングを価値あるものとしている多くのメリットを欠いています。
（例えば、即座の満足、目に見える進捗）
実際、リファクタリング中の3日間は、外から見たら目に見える進捗は有りません。
しかし、その後のコーディングの進み具合には大いに貢献しましたし、コードレビューをやったのと同じ効果がありました。（バグもいくつか発見しました）
使ったのはTemplate Methodだったのですが、具体的な手順として、
(1)類似したコードから異なるコードを分離し、差異部分を抽出
(2)差異部分を同じシグニチャを持つメソッドを作成する
(3)メソッドの引き上げ
とあり、例題のコードを使って説明されていて、分かりやすいものでした。
XP エクストリームプログラミング 入門
ソフトウェア開発の究極の手法
ピアソン・エデュケーション(2000)
ソフトウェア設計
Kent Beck
★★★★
Amazon.comでソフト関係の本を何冊か買ったことがあるのだが、第一のお勧めに、この本があがっていた。Amazon.comでの評価は４つ★である。書店で翻訳を見つけたので早速買った。
私なら、この本で述べられている手法を、究極のソフトウェア開発と言う勇気はない。著者も言うように個々の手法のほとんどは、昔から言われていることである。著者がこの方法の組み合わせで成功したのは、プロジェクト規模が小さかったことと、コンペティタがいなかったからではないか。共感できる部分もあるが、かなり読みにくい本である。ペアを組んで作業する方法や、テスト可能にするためにコードをシンプルにする等、参考にできそうなところもある。レビューやインスペクションについて、全く述べていないところが面白い。
どの手法に対してもそうであるが、重要なのは、XPの通りに実行することではなく、状況に応じて必要な部分を取り入れる柔軟さであろう。
・必要なことは、数回の大きな修正ではなく、多数の小さな修正である。
・XPは今日の問題を解くために、今日いい仕事をする。そして、複雑な機能は将来必要なときに、追加できると自分の能力を信じればよい。作りこんで結局使われない場合が多い。
・最良の戦略は実際に差し迫った問題を解く間、多くのオプションを保留しておくことである。
・プロジェクト初期に多くの投資を行うことは、災難を起こすレシピである。
・負けないために仕事をするのではなく、勝つために仕事をする。勝つために必要なことは何でもやる。そうでないことは何もしない。
・シンプルなシステムをすばやく稼動（運用）させる。そして新しいバージョンのリリースを極めて短いサイクルで行う。
・まず単体テストのコードを書き、コーディング、テストを繰り返す。
・二人のプログラマーが1台のマシンに向かい、コーディングする。
・リファクタリング
・誰でも全てのコードを変更できる
・タスク完了の度に、システムを結合しビルドする。
・週40時間以上働かない。
・ユーザをチームに加える。
・テストを自動化し、テスト結果を機械的に判定できるようにする。
達人プログラマー
システム開発の職人から名匠への道
ピアソン・エデュケーション(2000)
ソフトウェア設計
Andrew Hunt and David Thomas
★★★★☆
実践的な開発手法。役に立ちそうなアイディアとアドバイスがたくさん詰まっており、開発者に強く勧める。DRY、直交性、リファクタリング・・・すぐにでも使いたいものがたくさんある。
私が参考になった部分を書き出すと、
・常にあなたの知識ポートフォリオに投資すること。例えば毎年新しい言語を学習する。月に1冊は読書する等。
・DRY(Don't Repeat Yourself)原則。同じことを2箇所以上に記述し、片方を修正するときに、もう片方も修正しなければいけない場合、DRY原則に反している。
・直交性。ある種の独立性のこと。例えばデータベースのアルゴリズムとユーザーインタフェースは直交しているべきである。
・目標を見つけるには曳光弾を使う。発展的なプロトタイピング。（撃ってから狙えと言う言葉を思い出します）
・GUIのメリットはWYSIWYG--What You See Is What You Get（見たとおりのものが結果として得られる）。デメリットはWYSIAYG--What You See Is All You Get（見たとおり以上のものは得られない）。
つまり設計時に意図された以上のことはできないと言うことです。（AccessのQueryのデザインビューがよい例でしょう。UNIONとか副問い合わせを考えると。）
・起こりえないことは表明(assertion)を用いてそれを証明すること。
・抽象概念はコード上に、詳細はメタデータ上に置くこと。全般的なことをプログラムし、それ以外の特殊なことはどこか他の所（つまりコンパイル済みコードの外側）に持っていく
・コーディングは機械的な作業ではない。機械的な作業ならば、プログラマはCASEツールによって駆逐されていただろう。
・いつリファクタリングを行うべきか？①DRY原則に反している②直交性の原理に反している③時代遅れの知識④パフォーマンスの改善
・コーディングの際にはテストすると言うことを意識してコードを書く
・早めにバグが見つかるほど修正は安く上がる。「少しコーディングして少しテスト」する。
・コードとドキュメントは同じモデルの２つのビュー。DRY原則に反しないよう例えば仕様書をデータベース・スキーマに変換する等。
・あなたの作品に署名すること
等などです。
近代科学社(1980)
ソフトウェア設計
Glenford J. Myers
★★★★
テスト技法に関する古典。テストにかかわるすべての人に薦めたい。理論面に偏ることなく、心理学的、経済学的な考察も貴重である。数学の証明のように、論理を追うのに少々疲れるところもあるが、結論だけにでも目を通す価値は十分ある。
参考になった部分を挙げると、
・テストとはプログラムが正しく動くことを示すことではなく、エラーを見つけるつもりでプログラムを実行する過程である。
・テストは破壊的な過程であり、建設的な考えを持った一般的な人間には難しい作業である。
・テストの原則
○結果が自分に都合のよいように見えると言う現象があるので、テスト結果をきちんと定義しておく。
○プログラマは自分の作ったプログラムをテストしてはならない。プログラミングは建設的な過程であり、一夜明けて破壊的なテストをすることは不可能である。
○テスト結果を完全に検査する
○テスト・ケースは、正しい予想できる入力条件だけでなく、誤った予想しない場合も考えて書く。
○プログラムが意図されたように動くかどうかと同時に、意図されなかった動きをするかどうかをしらべる。
○テスト・ケースも使い捨てにしてはならない。
○エラーは見つからないだろうという仮定のもとにテストの計画を立てない。
○プログラムのある部分でエラーが存在する確率は、その部分ですでに見つかったエラーの数に比例する。
・レビュー、ウォークスルーは、ターゲットを使わないテストである。
・テストケースの設計では、どの方法でも、それ単独では不十分であり、さらにほかの方法と組み合わせても完全とは保証されない。
・モジュールテストでは例えば論理網羅（ホワイトボックス・テスト）を基本として、ブラックボックス・テストの集合で補足し、次に限界条件をカバーするテストケースを追加する。
・モジュール同士の結合を、トップダウンで行う方法と、ボトムアップで行う方法のメリット、デメリットを検討し、ボトムアップが有利な点が多いと結論付けている。
・エラー位置発見の原則
○考えよ。
○いきづまったときは、明日までのばそう。
○いきづまったときは、その問題を他人に説明しよう。
○デバッグ道具は２番目の手段としてつかおう。
○ 実験を避けよう。実験は最後の手段である。
等である。
