てけノート

on the foot of giants

【読書メモ】人月の神話

      2015/10/17


1、人月単位でプロジェクトの工数を見積もるのは不可能。
コミュニケーションコストは組み合わせ爆発。

2、チーム構成
役割分担が重要。
アーキテクトが何をするのか決めて、
仕様書を書く人、
インプリメンテーションする人、
テストする人、
事務・管理をする人
でチームを作るとよい。

3、コンセプトの完全性
設計思想が細部に至って完全であること。
パーツごとの矛盾などがなくなる。
使いやすさが決定的要因となるので、アーキテクトが大筋を決めておくべき。

4、セカンドシステム症候群
初代の設計思想に反した、ムダな機能の装飾。
統一感がなく矛盾した、不効率なデザイン。
多機能は使いやすさを向上させるとは限らない。

5、アーキテクトからの伝達
アーキテクトの役割は何をすべきか決めることであり、開発まで口を出さない。
しかし、同時にインプリメンテーションの方法のひとつくらいは持っておくべき。
ミーティングは定期的に開き、スケールの大きいものは年1、2回。

6、プロジェクト管理における手引書の運用
常に更新可能かつ参照可能なもの。コミュニケーションの労力をいかに減らすか。
アーキテクトは常に、製作の主任が製作に集中できるような環境整備を図る。

7、仕様書のフォーマット
何のために、何を、いつ、誰が、どこで、いくら。

8、ベータ版は捨てるつもりで
ベータ版は使い物にならない。捨てるつもりでいる。
バグ改修含むメンテナンスコストは全体労力の40%を超える。
だからウォーターフォールはやめるべきで、
利用可能なモデルが常に存在し、それを改修・漸増させるように開発を行う。
毎週リリースしよう。

9、バグをどうなくすか
独立したモジュール単位でテストを行う。本番環境で。
バグがないと保証されているモジュールに、新規テスト対象を足してデバッグを行う。
不可能な場合は、ダミー(テストデータ、疑似データなど)でテストする。
一回に複数追加してテストしない。

10、進捗の管理
マイルストーンを可視化し、達成度を日々報告できる第三者が必要。

11、プログラミングは難しい
本質的に管理しにくい複雑性を持つ。対処法として
オブジェクト指向
コードの再利用
コードへのヘルプの付与(自己文書化)

 - 読書