Head Firstソフトウェア開発

序章
    本書の対象読者
    あなたがどう思っているのか、わかっています
    メタ認知
    脳を服従させるためにできること
    注意事項
    テクニカルレビューチーム
    謝辞

1章　優れたソフトウェア開発
    トムのトレイルをオンライン化する
    ほとんどのプロジェクトには2つの大きな懸案事項がある
    開発のビッグバンアプローチ
    未来の姿：2週間後
    通常、ビッグバン開発は最終的にひどい状態になる
    優れたソフトウェア開発とは……
    反復しながら目標に到達する
    それぞれの反復はミニプロジェクト
    それぞれの反復は高品質ソフトウェア
    顧客は必ず変更する
    調整はみなさんの仕事
    しかし、大きな問題が……
    反復は変更に（ある程度）自動的に対処する
    ソフトウェアはリリースされるまで完成しない
    ソフトウェア開発ツールボックスのためのツール

2章　要件の収集
    オリオン・オービッツを近代化する
    詳しい情報を得るために顧客と話をする
    顧客とブルースカイを行う
    ブルースカイ会議がこのようになることがある……
    人々が実際に行っていることを知る
    要件は顧客指向でなければいけない
    顧客のフィードバックにより要件を発展させる
    ユーザストーリはプロジェクトの内容を定義する……見積りはその期間を明確にする
    職場での会話
    プランニングポーカーを行う
    推測を懸命に審議する
    大きなユーザストーリ見積りは悪いユーザストーリ見積りである
    目標は収束すること
    反復サイクルを見積もるための要件
    ついにプロジェクト全体を見積る準備ができた

3章　プロジェクト計画
    顧客はソフトウェアを今必要としている！
    顧客と一緒に優先付けする
    マイルストーン1.0に含めるものを知っている（おそらく）
    期限に間に合わない場合は優先順位を付け直す
    人員が増加すると成果が下がることもある
    適切なマイルストーン1.0へ向けて努力する
    反復は簡潔であるべき
    計画を現実と照らし合わせる
    見積りでは速度を使ってオーバーヘッドを考慮する
    プログラマは非現実的な日数で考える……
    開発者は現実的な日数で考える……
    反復が長すぎるのはどんなとき？
    反復に分割する前に速度を適用する
    評価のとき
    怒った顧客に対応する
    壁の管理用掲示板
    チームを破滅させる方法

4章　ユーザストーリとタスク
    iSwoonの導入
    タスクの見積りはつじつまが合っているか？
    残りの作業だけをプロットする
    掲示板にタスクを追加する
    タスクに取り掛かる
    タスクは進行中状態にあるときだけ進行する
    一度に2つのことに取り組むとどうなるか？
    最初のスタンドアップミーティング……
    タスク1：Dateクラスの作成
    スタンドアップミーティング：5日目（第1週の最後）……
    スタンドアップミーティング：2日目、第2週……
    本章に横槍が入ります……
    計画外のタスクを管理する必要がある
    予定外のタスクによりバーンダウンレートが上がる
    速度は役立つが……
    すべきことがたくさんある……
    ……しかし、現状を正確にわかっている
    速度の真実

5章　十分な設計
    iSwoonが重大なトラブルに陥っている……
    この設計は単一責任の原則を破っている
    設計段階の複数の責任を見つける
    複数の責任から単一の責任へ移行する
    設計ではSRPに従うべきだが、DRYにも従うべき……
    リファクタリング後のスタンドアップミーティング……
    計画外のタスクも単なるタスクにすぎない
    デモそのものもタスクの一部である
    すべてが完了したら、反復は終了

6章　バージョン管理
    新たな契約を得る−BeatBoxプロ
    次はGUI作業……
    顧客に新しいBeatBoxのデモを行う
    バージョン管理を始めましょう
    まずプロジェクトを準備する……
    ……するとコードのチェックインとチェックアウトができる
    ほとんどのバージョン管理ソフトは問題を解決してくれる
    サーバは変更をマージする
    変更点をマージできない場合にはコンフリクトを示す
    さらなる反復、さらなるユーザストーリ……
    複数のバージョンがある……
    適切なコミットメッセージを付けると古いバージョンの発見が容易になる
    これでバージョン1.0をチェックアウトできる
    （緊急）スタンドアップミーティング
    バージョンにタグを付ける
    タグ、ブランチ、トランク、どうなっているのだ！
    今回はバージョン1.0を本当に修正する……
    現在は2つのコードベースがある
    ブランチを作成すべきでない場合……
    適切なブランチ作成の秘訣
    バージョン管理で実現できること……
    バージョン管理はコードが実際に正しく動作するかどうかは確認できない……
    ソフトウェア開発ツールボックスのためのツール

6.5章　コードのビルド
    開発者は読心術者ではない
    1つの手順でプロジェクトをビルドする
    Ant：Javaプロジェクト用のビルドツール
    プロジェクト、プロパティ、ターゲット、タスク
    優れたビルドスクリプトは……
    優れたビルドスクリプトは基本的な処理以上の働きをする
    ビルドスクリプトもコードである
    新たな開発者、テイク2
    ソフトウェア開発ツールボックスのためのツール

7章　テストと継続的インテグレーション
    問題はいつでも発生する……
    システムを調べるには3つの方法がある……
    ブラックボックステストは入力と出力に着目する
    グレーボックステストはコードにより近付く
    ホワイトボックステストは内部情報を使う
    1つの手順ですべてをテストする
    テストフレームワークを使ってテストを自動化する
    フレームワークを使ってテストを実行する
    CruiseControlを使ったCIの管理
    テストで正常な機能が保証されるのか？
    すべてのコードのテストとはすべての分岐をテストすることを意味する
    網羅率レポートを使って網羅されている部分を確認する
    十分な網羅率を実現するのは必ずしも容易ではない……
    CM（構成管理）で実現できること……
    ソフトウェア開発ツールボックスのためのツール

8章　テスト駆動型開発
    最後ではなく最初にテストする
    そこで、テストを最初に行う……
    テスト駆動型開発へようこそ
    最初のテストは……
    見事に失敗する
    テストを緑にする
    赤、緑、リファクタリング……
    TDDではテストが実装を後押しする
    タスクの完了とは必要なすべてのテストを用意し、すべてに合格すること
    テストに合格したら先に進む！
    簡潔なら依存関係を避けられる
    テスト可能なコードを常に記述する
    テストが困難になったら、設計を吟味する
    Strategyパターンは1 つのインタフェースの複数の実装を提供する
    テストコードはテストと共に保持する
    テストはより優れたコードを生み出す
    テストが増えると必ずコードがもっと増えることになる
    Strategyパターン、疎結合、オブジェクトの代役
    異なるけれども似ている多くのオブジェクトが必要
    オブジェクトを生成したらどうなるか
    モックオブジェクトは本物のオブジェクトの代役を務める
    モックオブジェクトは正しく機能するオブジェクトの代役
    優れたソフトウェアはテスト可能である……
    緑にするのは容易ではない……
    テスト駆動型開発者の1日
    ソフトウェア開発ツールボックスのためのツール

9章　反復の終了
    反復はほとんど完了……
    ……しかし、できることがたくさん残っている
    システムテストを実行しなければいけない……
    ……しかし、誰がシステムテストを行うのか？
    システムテストにはテストすべき完成したシステムが必要
    優れたシステムテストには2つの反復サイクルが必要
    反復が増えると問題も増える
    効果的なシステムテストの特徴トップ10
    バグの一生（および消滅）
    バグを見つけた……
    バグレポートの分析
    しかしまだできることがたくさん残っている……
    反復の点検の時間
    反復を点検するための質問
    その他のことを仕上げる際の一般的な優先事項リスト……
    ソフトウェア開発ツールボックスのためのツール

10章　次の反復
    正常に機能するソフトウェアとは何か？
    次の反復を計画する
    速度は……現実を考慮する
    やはり顧客が中心
    他の誰かのソフトウェアもやはりソフトウェアにすぎない
    顧客の承認は？確認しよう！
    コードのテスト
    ヒューストン、確かに問題がある……
    誰も信じない
    誰がコードを記述したかは問題ではない。問題が自分のソフトウェアにあれば自分の責任である
    プロセスがない場合
    プロセスがある場合

11章　バグ
    反復2のあらすじ
    まず、顧客と話す
    優先度1：ビルドできるようにする
    コードを修正できたが……
    ……しかし、機能を修正する必要がある
    正常に動作する機能を判別する
    これで何が正常に機能しないかがわかる
    あなたならどうする？
    見積りのためのスパイクテスト
    スパイクテストの結果から何がわかる？
    チームの直感が重要
    顧客にバグ修正の見積りを提示する
    よい状態に見える……
    ……そして反復を成功裏に完了する！
    そして顧客も満足する
    ソフトウェア開発ツールボックスのためのツール

12章　現実の世界
    ソフトウェア開発プロセスを突き止める
    優れたプロセスは優れたソフトウェアを提供する
    正装が必要……
    その他の情報源……
    より多くの知識 == より優れたプロセス
    ソフトウェア開発ツールボックスのためのツール

付録i　未収録事項
    #1.UMLクラス図
    #2.シーケンス図
    #3.ユーザストーリとユースケース
    #4.システムテストと単体テストの対比
    #5.リファクタリング

付録ii　テクニックと原則
    開発テクニック
    開発原則