我很抱歉，如果这是重复的，但问题搜索术语非常通用。
我在一家小型（ish）开发公司工作。我说小，但公司实际上是一个公平的规模;但是，我只是第二个全职开发人员，因为大多数过去的工作是围绕承包商组织的。
我能够定义内部项目流程和政策 - 显而易见的东西，如SCM和单元测试。方法论超出了我正在整理的文档的范围，但我真的想让我们更加精简（甚至可能是敏捷？）方向。
我觉得我有很多好的练习建议，但没有足够的坚实动力让我的文档成为我想要的精神指南。我把文件分成了“原则”和“建议”。建议很容易想出来。使用SCM，争取一步，定期计划的构建，首先进行单元测试，随时记录文档......但是，列出应该通知这些建议的原则一直很粗糙。
我想出了“工具为我们工作;我们永远不应该为工具工作”和一个针对我们的质量保证（过度手动）的朦胧条款我想读“乏味是根源所有的邪恶“。
我不想错过这篇文章的机会给我们一个良好的内部开端，甚至可能将我们推向敏捷。我错过了什么原则？
编辑4/15 -
我可能对本文档的范围含糊不清。就目前而言，我的合作伙伴和我计划遵循的政策。到目前为止，我们已经获得了本地工具，源代码控制等选择的自由统治，以及我们在开发过程中遵循的一般过程（例如构建，部署，是否使用持续集成......）。
理想情况下，我还希望将此文档作为进一步改进流程的模型。我主要是考虑质量保证，并且可能会将我们的项目管理推向更轻松和迭代的事情。