Joel on Softwareを読んだ

再読。読み物としても面白い。

ジョエルテスト

ソフトウェアチームのクオリティを評価するテスト。

1. ソース管理してる？
2. ワンストップでビルドできる？
3. デイリービルドしてる？
4. バグデータベースはある？
5. 新しいコードを書く前にバグを直している？
6. アップデートされているスケジュールがある？
7. 仕様書はある？
8. プログラマは静かな環境で作業している？
9. 手に入る最高のツールを使っている？
10.テスタはいる？
11.採用面接のときにコードを書かせている？
12.ユーザビリティテストはしてる？

なぜ仕様書を書く必要があるか

• もっとも重要な役割はプログラムをデザインすること。
• コミュニケーションにかかる時間を節約できる。
• 仕様書がないとスケジュールを立てられない。
• 仕様書を書かないことは、時間の節約にはならない。

仕様書に入れるもの

• 自己防衛のための注意書
• 一人の作成者
• どのように使われるかのシナリオ
• 対象外
• 概要
• 詳細、決定されたことを記述する
• 未解決の問題
• ノート
• アップデート、リビジョンマーク

スケジュールの作り方

• Excelを使う
• 単純に保つ。暗記しておけるぐらい単純なもの
• 作業をするプログラマが見積もる
• タスクの粒度を細かくする
• 当初と現在の見積もりを記録する
• 経過時間を毎日アップデートする
• デバッグの時間を入れる
• バッファを入れる

生産性の鍵

ただ始めること。

報償金有害論

ポジティブな評価でも、思っていたほどではなかった場合にはマイナス。
正しく評価が行われる場合、ほとんどの人は自分の評価にがっかりする。
報償は職場では機能しない。

タスク切り替えは有害

同時に一つより多くの作業をさせるべきではない。

顧客は自分が何が欲しいか分かっていない

顧客の問題を好ましい仕方で解決するデザインを見つけ出す必要がある。

知識労働者のパフォーマンスの測定はできない

マネージャというのは測定システムに基づく評価を報償と結びつけたがる。
労働者を完全に監視できない場合には、測定機能障害を避けられない。

実装する前にデザインする必要がある

何事も見た目ほど簡単ではない。リスクを削減できる。

車輪の再発明

それがビジネスの核となる機能なら、何が何でも自分でやる

参入障壁

人々を乗り換えさせる唯一の戦略は、乗換えへの障害を取り除くこと。
止められないなど、ロックインするのも参入障壁の一つ。

Joel on Software