私たちの開発プロセス/ポリシーを形作るチャンス [終了]

Question

重複していたら申し訳ありませんが、質問の検索用語は非常に一般的です。

私は小さな（っぽい）開発会社で働いています。小さいとは言いましたが、実際にはかなりの規模の会社です。ただし、これまでの仕事のほとんどは請負業者を中心に組織されていたため、私は 2 人目のフルタイム開発者に過ぎません。

私は、SCM や単体テストなどの内部プロジェクト プロセスとポリシーを定義する立場にあります。方法論は私がまとめている文書の範囲外ですが、私たちはよりスリムな (そしてもしかしたらアジャイルも?) 方向に進めていきたいと思っています。

優れた実践方法に関する推奨事項はたくさんあると感じていますが、私の文書を私が望む精神的なガイドにするための確固たる動機が十分ではありません。この文書を「原則」と「勧告」に分けました。推奨事項は簡単に思いつくことができました。SCM を使用し、定期的にスケジュールされた 1 ステップのビルドを目指し、最初に単体テストを行い、進みながら文書化します...しかし、これらの推奨事項に影響を与えると考えられる原則を列挙するのは大変です。

私は、「ツールは私たちのために機能します。私たちは決してツールのために働くべきではありません」と、私が読みたいのは「退屈は諸悪の根源である」という、私たちの QA (過度にマニュアル化されている) に向けられた曖昧な条項です。

このドキュメントによって、社内で良いスタートを切ることができ、場合によってはアジャイルに向けて前進することもできるチャンスを逃したくありません。私に欠けている原則は何ですか?

編集 4/15 -

このドキュメントの範囲について曖昧だったかもしれません。今のところ、私と共同開発者が従う予定のポリシーです。これまでのところ、ローカル ツール、ソース管理などの選択と、開発で従う一般的なプロセス (ビルド、デプロイ、継続的統合を使用するかどうかなど) については自由に決められています。

理想的には、この文書がさらなるプロセス改善の基礎となるモデルになることを願っています。私は主に QA について考えており、プロジェクト管理をより軽量で反復的なものに向けて推進するかもしれません。

Answer 1

の アジャイルマニフェスト そして その原則 さらにいくつかのアイデアが役立つかもしれません