如果这是重复,我很抱歉,但问题搜索术语非常通用.

我在一家小型(ish)开发公司工作.我说小,但公司实际上是一个公平的规模;然而,我只是第二个全职开发人员,因为大多数过去的工作是围绕承包商组织的.

我能够定义内部项目流程和政策 – 显而易见的东西,如SCM和单元测试.方法论超出了我正在整理的文档的范围,但我真的想让我们更加精简(甚至可能是敏捷？)方向.

我觉得我有很多好的练习建议,但没有足够的坚实动力使我的文档成为我想要的精神指南.我把文件分成了“原则”和“建议”.建议很容易想出来.使用SCM,争取一步,定期计划的构建,首先进行单元测试,随时记录文档……但是,列出应该通知这些建议的原则一直很粗糙.

我想出了“为我们工作的工具;我们永远不应该为工具工作”和针对我们的质量保证(过度手动)的朦胧条款我想读“乏味是一切罪恶的根源” .

我不想错过这篇文章的机会给我们一个良好的内部开端,甚至可能将我们推向敏捷.我错过了什么原则？

编辑4/15 –

我可能对本文档的范围含糊不清.就目前而言,我的合作伙伴和我计划遵循的政策.到目前为止,我们已经获得了关于本地工具,源代码控制等的选择以及我们在开发中遵循的一般过程(例如构建,部署,是否使用持续集成……)的自由统治.

理想情况下,我也希望本文档成为进一步改进流程的模型.我主要是在考虑质量保证,也许可以将我们的项目管理推向更轻松,更迭代的事情.

最佳答案
Agile Manifesto和
its principles可能有助于提出更多想法