やさしいソフトウェアスケジュール

１．Microsoft Excelを使う。
Microsoft Projectの問題点
・Microsoft Project、依存関係に重点を置いている。ソフトウェアは、依存関係は明らかで、公式に管理するものではない。
・「再平準化」とは作業を整理して、別の人に再割り当てすることを意味するが、ソフトウェアではこれは意味をなさない。プログラマは交換可能ではないからだ。リタのバグをジョンが直すのに比べ、７倍長くかかる。

２．単純に保つ。
ジョエルの標準フォーマット

機能・タスク・優先度・当初見積・現在見積・経過時間・残り時間

３．それぞれの機能はいくつかのタスクからなる。
スケジュール作りの最も重要な部分は、このタスクリストを作ることだ。したがって鉄則は・・・。
４．そのコードスケジュールを立てられるのは、それを書くプログラマだけ。
マネジメントがスケジュールを書いてそれをプログラマに渡しているようなプロジェクトは失敗する運命にある。その機能を実装するのにどんなステップが必要なるかが分かるのは、その作業をするプログラマだけだ。そしてそのプログラマだけが、それぞれのステップにどれだけかかるかを見積もることができる。
５．タスクの粒度を細かくすること。
・タスクを分割することで機能をデザインすることを強いられる。
・タスクを２時間から６時間に分割
６．当初の見積と現在の見積を記録しておく。
・プログラマは、物事にどれぐらい時間がかかるか推測する方法を全然分かっていない。
　絶えず学び、学ぶにつれて絶えずスケジュールをアップデートする限りは、機能する。
７．経過時間カラムを毎日アップデートする。
８．休暇や祝日、その他のことのための項目をいれる。
９．スケジュールにデバッグ時間を入れる。
プログラマは、修正できるバグがある限りは、消して新しいコードに取りかかるべきではない。
２つの理由で、バグの数は常に可能な限り低くしておかなければならない。
・コードを書いたのと同じ日にバグを直す方が簡単。
・あなたがバグの原因をいつ発見し、いつそれを解決するのか見積もるのは不可能。
常に、バグを０にしておいても、内部テスタやβテスタ達が本当に難しいバグを見つけたときに、必然的に多くのバグ修正作業が発生するからだ。
１０．統合のため時間をスケジュールに入れる
１１．スケジュールにバッファを入れる。
物事は超過する傾向がある。考慮すべき重要なバッファは次の２種類だ。
(1)当初の見積よりも長くかかるタスクのバッファ。
(2)やらなければならないとは知らなかったタスクのためのバッファ。
１２．決してマネージャにプログラマの見積を減らさせない
・現在見積カラムだけをいじらせろ。
・３ｎ時間かかることがｎに見える。
１３．スケジュールは積み木みたいなもの
たくさんの積み木を持っていて，それを箱に詰め込むことができない場合，２つの選択肢がある。
もっと大きな箱をてにいれるか，いくつかの積み木を取り除くか。
スケジュールを作れば，作業を始める前に何かカットしなければならないと気づき，そして簡単で楽しい機能をカットし，有用かつ重要な機能だけをやるだろう。