友人とまとめました。こちら　置いてあるものの複製です。

(UN) Effective Waterfall

謝辞

　私たちは、先輩方の厳格な指導のもと、多くのメンバーと失敗や困難を共にしてきました。そんな中で常に私たちと共にあり続けたのが「ウォーターフォール開発」でした。偉大な先輩方、かつてのメンバー、及びそこから得られた素晴らしい経験に感謝を込めて、この「(UN)Effective Waterfall」をまとめました。

1. 原則

原則ウォーターフォールであること。近年、開発手法が取り沙汰されているが、ウォーターフォールは、どのような開発プロジェクトでも成功に導くことができる、一般的かつ普遍的なな指針・手法である。
工程に疑義が生じた場合は、記録を行い、改善プロセスの中で組織的な改善を図ること。
顧客と価値共有を図る事。顧客にとっての価値は、まずは予算、次に機能である。

2. 基本設計

アプリケーション方式を初め、アーキテクチャや実現方法については、主担当以外にも、類似した案件を行なった人に他の良い方法がないかを聞き、比較する事。相反する意見が出された場合、実績等を判断し、総合的に上席が判断を下さなければならない。
新しい技術より、実績のある技術を採用する事。短期開発のため、評判のよいフレームワークについての検討はしてもよい。（枯れた技術の水平思考）
プログラム変更にはテスト等の工数がかかるため、できる限り設定のみで変更できるように設計する事。
将来的な変更可能性など、汎用性を考慮し、SQL文などクエリはできる限りDB上のテーブルに保存し、顧客要求にAjailに対応できるよう設計する事（ママ）。最低限、ループ処理でまわすクエリのorder by句とbreak キーはテーブル上で設定できなければならない。
全ての人が閲覧、編集出来るよう、ドキュメントはMicrosoft Wordもしくは Excelで記述すること。UMLツールなど特定の技術に依存したものの利用は避けること。(learn once, write anywhere)
設計書は分かりやすいことが重要なので、専門的な用語の利用は避けること。具体的にはクラス、オブジェクトなど。

3. 詳細設計

トレーサビリティ確保の為、詳細設計書のタイトルには必ず通し番号をつけること。また、実装コードの関数名にも同一の通し番号を付与すること。
扱いやすいテーブル定義とすること。正規化しすぎると扱いにくいため、正規化されることよりも拡張性を持たせておくこと。
ライブラリ等、オープンソースや3rdパーティ製のものは、テストされていない等の問題が発生するため絶対に使用しないこと。アルゴリズム等、重要な部分は、一から設計・実装する事。
インターネット上の掲示板やブログ等に書かれているサンプルコードは充分なテストがされていないため、できる限り参考しないこと。工数削減等のために、どうしても使用する場合は、上司の許可の元、慎重に導入を検討すること。テストを必ず行うこと。(戦術とは、持てる手段で何ができるかを考える事である。)
全てのレビューは主担当、上席、関連する機能の担当者(主担当以外は、協力会社を除く)を全て集めて行い、誤解が起こらないよう、会議の場で資料内容を説明すること。また、資料は事前に紙で印刷して置くこと。

4. 実装

既存開発の類似コードがある場合は、コピーアンドペーストなどで流用すること。自身のプロジェクトの工数を短縮すること。完成済のコードにデグレ等の影響を与えないようにすること。「寝た子を起こすな。」
複数の機能から、同じ処理を行う場合、共通化よりも、機能仕様の変化に対応を優先させるため、別々に作成すること。
ハード性能はどんどん新しくなるので、プログラムの最適化は考えなくてよい。
事故防止の為、プログラマが不具合や仕様の間違いを発見した場合は速やかにリーダーに報告し、指示を待って行動すること。リーダーは、適時、古くからのベテランメンバーを招集し協議をおこなうこと。
他のコンポーネント間との間で設計上の問題が発生した場合は、次の全体ミーティングの議題とし、部門間で協議すること。
チームメンバーを思いやってコーディングを行うこと。例としては、不要に見えたからと行って自分の都合でコメントアウトされた行を削除してはいけない。チームメンバーにとって意味のあるものかもしれないのだから。また、勝手にファイル名や関数名を変えてもいけない。決まったところに決まったものがないと、チームメンバーが見つけられないかもしれない。
スパゲッティコードになるのを防ぐ為、構造的なプログラミングを行うこと。具体的には、for,whileブロック内でのbreak,continueの禁止。不要なreturnの禁止。
ソースコードを修正する場合、元のソースコードのバックアップは残して置くこと。
バグのあるコードをコミットする事で他の人に影響を与えたりする事のないよう、リリース済のコードのみをコミットする事。
コーディング規約を設ける場合、コードレビューを行うこと。規約が守られているかどうかの点までチェックを行うこと。
※(参考)割れ窓理論―軽微な犯罪も徹底的に取り締まることで、凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。