如果这是重复的，我很抱歉，但问题搜索词非常通用。
我在一家小型（ish）开发公司工作。我说小，但公司实际上是一个公平的规模；但是，我只是第二个全职开发人员，因为过去的大部分工作都是围绕承包商组织的。
我能够定义内部项目流程和政策显而易见的东西，例如 SCM 和单元测试。方法论超出了我正在整理的文档的范围，但我真的很想将我们推向更精简（甚至可能是敏捷？）的方向。
我觉得我有很多好的实践建议，但没有足够的动力让我的文档成为我想要的精神指南。我将文件分为“原则”和“建议”。很容易提出建议。使用 SCM，争取 1 步，定期安排构建，首先进行单元测试，边做边记录...... 但是，列出应该为这些建议提供信息的原则是粗略的。
我想出了“工具为我们工作；我们永远不应该为工具工作”和一个针对我们的 QA（过于手动）的模糊条款，我想阅读“乏味是万恶之源” .
我不想错过这个文档给我们一个良好的内部开始甚至推动我们走向敏捷的机会。我缺少什么原则？
编辑 4/15 -
我可能对本文档的范围模棱两可。目前，这是我和我的共同开发人员计划遵循的政策。到目前为止，我们可以自由选择本地工具、源代码控制等，以及我们在开发中遵循的一般流程（例如构建、部署、是否使用持续集成……）。
理想情况下，我还希望本文档成为进一步改进流程的模型。我主要考虑 QA，也许会推动我们的项目管理朝着更轻松和迭代的方向发展。