プロジェクト管理など

メモ】http://www.atmarkit.co.jp/channel/channel_index.html#dev

フレームワークObjectWorks
http://www.atmarkit.co.jp/farc/rensai/heaven05/heaven05c.html
限りなく精密な設計は、限りなくコーディングに近くなり、実装者の負担を設計者に乗せるにすぎないという事態を招きます。
１つは統一的な振る舞いです。更新時に確認画面があるのか、検索時は子画面でするのか戻るはどこに戻るのか……といった統一されたシステム全体の動きの定義です。もう1つは個々の機能ごとの振る舞いです。どの項目がDBのどのカラムと関係し、どんなロジックが関係してどんなチェックが行われるのか、などです。
　しかし、それ以外の部分、つまり、入力値の型は合っているか、そのチェックは、ロジックに入る前に行うのか、そもそも、データベースにつながらないときにプログラム何行目でエラーにするのか……、そういった情報は「設計しない」「実装者に任せる」という選択肢を取ることによりチーム全体の負荷を幅広く分散することが可能です。
もちろん、コードの標準を制定し、プロトタイプで「大体の書き方」を示唆することが必要です。
http://www.atmarkit.co.jp/farc/rensai/heaven06/heaven06a.html
私がプロジェクトを運営するときの方針の1つとして「無駄なことだと思っても皆に知らせておく」というものがあります。セキュリティに問題がない範囲でプロジェクトメンバー全体に情報を行き渡らせておくというのは、スムーズなプロジェクト運営を行ううえで非常に効果があります。