これが重複している場合は申し訳ありませんが、質問の検索用語はかなり一般的です。
私は小さな（っぽい）開発会社で働いています。私は小さいと言っていますが、会社は実際にはかなりの規模です。ただし、これまでのほとんどの作業は請負業者を中心に編成されていたため、フルタイムの開発者は私が 2 人目にすぎません。
私は、社内のプロジェクト プロセスとポリシー (SCM や単体テストなどの明白なもの) を定義する立場にあります。方法論は、私がまとめているドキュメントの範囲外ですが、私たちをより無駄のない (そしておそらくアジャイル?) 方向に推し進めたいと思っています。
良い実践の推奨事項はたくさんあるように感じますが、私の文書を私が望むスピリット ガイドにするための十分な確固たる動機はありません。ドキュメントを「原則」と「推奨事項」に分けました。おすすめは簡単に出てきました。SCM を使用し、定期的にスケジュールされた 1 ステップのビルドに努め、最初に単体テストを行い、作業を進めながら文書化します。ただし、これらの推奨事項を通知するはずの原則をリストするのは大雑把です。
私は、「ツールは私たちのために働く。決してツールのために働くべきではない」と、「退屈はすべての悪の根源」と読みたい QA を目的とした漠然とした条項 (これは過度に手作業でした) を思いつきました。 .
このドキュメントによって、社内で良いスタートを切る機会を逃したくはありません。欠けている原則は何ですか？
編集 4/15 -
このドキュメントの範囲について、私はあいまいだったかもしれません。今のところ、共同開発者と私が従う予定のポリシーです。これまでのところ、ローカル ツール、ソース管理などの選択、および開発で従う一般的なプロセス (ビルド、デプロイ、継続的インテグレーションを使用するかどうかなど) は自由に決定されています。
理想的には、この文書がさらなるプロセス改善の基礎となるモデルになることも望んでいます。私は主に QA について考えており、おそらくプロジェクト管理をより軽くて反復的なものに向けて微調整しています。