我正在寻找流程建议，我在网站上看到了一些。我喜欢听到的是你在公司，或者只是你和你的爱好项目中特别使用的东西。当然，欢迎任何与其他网站讨论这些主题的链接！
基于以下答案的一些问题：
答案 0 :(得分：11)
对于我的（小）公司：
我们首先设计UI。这对我们的设计来说非常重要，因为复杂的用户界面几乎会立即疏远潜在买家。我们在 paper 上对我们的设计进行原型设计，然后在决定设计细节时，准备View和任何适当的Controller代码，以便对我们的设计进行连续的交互式原型设计。
当我们向可接受的用户界面迈进时，我们会为应用程序的工作流逻辑编写 paper 规范。纸张价格便宜，通过设计进行搅拌可以保证您至少花费少量时间考虑实施而不是盲目编码。
我们的规格与我们的来源一起保持在版本控制中。如果我们决定进行更改，或者想要进行实验，我们会对代码进行分支，并立即更新规范以详细说明我们要使用此特定分支完成的操作。不需要对分支进行单元测试;然而，它们是我们想要整合回主干的任何东西所必需的。我们发现这鼓励了实验。
规格不是神圣的，也不属于任何特定的个人。通过将规范应用于源控制的民主环境，我们鼓励不断的实验和修改 - 只要记录在案，我们就不是说“WTF”了。后来，
在最近的iPhone游戏（尚未发布）中，我们最终获得了近500个分支，后来转化为近20种不同的功能，大量的概念简化（进度条上的“点击取消”而不是单独的按钮） ，一些被拒绝的想法，以及3个新项目。最棒的是每个想法都有记录，因此很容易想象出这个想法如何改变产品。
在每次主要构建之后（主干中的任何内容都会更新，单元测试通过），我们尝试让至少2个人测试项目。大多数情况下，我们试图找到对计算机知之甚少的人，因为我们发现设计复杂性而非简单性太容易了。
我们使用DOxygen生成我们的文档。我们还没有将自动生成纳入我们的构建过程，但我们正在努力。
我们不对代码进行审核。如果单元测试工作，并且源不会导致问题，那可能没问题 - 但这是因为我们能够依赖程序员的质量。这可能不适用于所有环境。
单元测试一直是我们编程实践的神灵。由于任何新代码在没有适当的单元测试的情况下都无法传递到主干，因此我们的主干覆盖范围相当好，而且我们的分支机构覆盖范围适中。但是，它不能替代用户测试 - 只是一种有助于达到这一点的工具。
对于错误跟踪，我们使用bugzilla。我们不喜欢它，但它现在有效。我们可能很快就会推出自己的解决方案或迁移到FogBugz。我们的目标是在我们达到0已知错误状态之前不发布软件。由于这种立场，我们对现有代码包的更新通常很少。
所以，基本上，我们的流程通常看起来像这样：
我们的过程无论如何都不是完美的，但完美的过程也意味着完美的人类和技术 - 而且这种情况不会很快发生。我们在计划中经历的纸张数量是惊人的 - 也许是我们与Dunder Mifflin达成合同的时候了？
答案 1 :(得分：5)
我不确定为什么这个问题被投了票。我认为这是一个很好的问题。谷歌搜索是一回事，并阅读一些随机网站，这些网站很多时候试图向你推销一些东西，而不是客观。另外一件事是要求那些开发人员/ IT管理人员分享他们的经验，以及哪些对他们的团队有效或无效。
现在这一点已经不在了。我相信很多开发人员都会指向“敏捷”和/或Scrum，请记住这些术语通常使用得非常松散，尤其是敏捷。我可能听起来很有争议，说这不是我的意图，但这些方法被过度炒作，尤其是Scrum，它更像是由Scrum顾问推销的产品，而不是“真正的”方法。话虽如此，在一天结束时，你必须使用对你和你的团队最有效的东西，如果它是敏捷/ Scrum / XP或其他什么，那就去吧。与此同时，您需要对此保持灵活性，不要对任何方法，工具或技术抱有信心。如果某些东西不适合你，或者你可以通过改变某些东西来提高效率，那就去吧。
更具体地说明您的问题。以下是对我有用的技术的基本总结（其中很多都是常识）：
整理与特定项目相关的所有文档和电子邮件，并通过中央位置让其他人可以访问（我使用MS OneNote 2007并将其用于我的所有文档，进程，功能和错误跟踪等等）
所有会议（您应尽量减少）应遵循行动项目，其中每个项目都分配给特定的人员。任何口头协议都应写入书面文件。所有文档都添加到项目站点/存储库中。 （在我的案例中是MS OneNote）
在开始任何新的开发之前，请准备一份关于系统能够做什么（以及它不会做什么）的书面文档。致力于此，但要灵活应对业务需求。文件的详细程度如何？足够详细，以便每个人都能理解最终系统的功能。
时间表很好，但要对自己和业务用户保持现实和诚实。我使用的基本准则：发布缺乏某些功能的质量和可用软件，而不是具有所有功能的错误软件。
您的开发者之间有开放的沟通渠道。团队以及您的开发人员和业务团队之间，但在一天结束时，一个人（或几个关键人物）应该负责做出关键决策。
有意义的单元测试。但不要迷恋它。 100％代码覆盖率！=没有错误，软件根据规格正常工作。
有代码标准和代码审查。承诺标准，但如果它在某些情况下不起作用则允许灵活性。
评论您的代码特别难以阅读/理解部分，但不要将其变成小说。
如果您已经在使用该类/方法，请返回并清理代码;实现新功能，修复错误等等。但不要仅仅为了重构而重构它，除非你没有别的事可做，而且你很无聊。
最后也是最重要的项目： 不要对任何特定的方法或技术有所了解。借用每个方面的最佳方面，找到适合您和您的团队的平衡点。
答案 2 :(得分：4)
答案 3 :(得分：1)
为了给出更好的答案，我公司的政策是尽可能使用XP，并遵循敏捷宣言中列出的原则和做法。
http://www.extremeprogramming.org/
所以这包括故事卡，测试驱动开发，结对编程，自动测试，持续集成，一键安装等等。我们在文档方面并不重要，但我们意识到我们需要生成足够的文档才能创建可用的软件。
坚果壳：