【読書メモ】人月の神話


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

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

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

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

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

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

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

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

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

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

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

シェアする

  • このエントリーをはてなブックマークに追加

フォローする