我想寻求流程建议，并在网站上看到了一些。 我想听听您在公司或个人爱好项目中具体使用的内容。 欢迎提供与这些主题相关的其他网站链接！
以下是可以基于其回答的一些问题：
对于我们（小）公司：
我们首先设计用户界面(UI)。这对于我们的设计来说绝对至关重要，因为复杂的UI几乎会立即疏远潜在的买家。我们在纸上制作原型，然后在确定设计的具体细节时，为我们的设计准备视图(View)和任何适当的控制器(Controller)代码，以进行连续的交互式原型设计。
随着我们朝着可接受的UI前进，我们会为应用程序的工作流程逻辑编写一份纸质规范书。纸张是便宜的，而且通过设计的不断推敲，可以确保您至少花费了一点时间思考实现而不是盲目编码。
我们的规范书与源代码一起保存在版本控制中。如果我们决定更改或想要尝试新的东西，我们就会分支代码，并立即更新规范书，详细说明我们想要通过这个特定分支实现什么。分支的单元测试不是必需的；但是，如果我们想将其合并回主干，则需要进行单元测试。我们发现这鼓励了实验。
规范书不是神圣的，也不属于任何特定的个人。通过将规范书提交到源代码的民主环境中，我们鼓励不断实验和修订 - 只要有记录，以便我们以后不会感到困惑。
在最近的一款iPhone游戏（尚未发布）中，我们最终拥有了近500个分支，这随后转化为近20个不同的功能、大量的概念简化（进度条上的“点击取消”而不是单独的按钮）、一些被拒绝的想法和3个新项目。最棒的是，每一个想法都有记录，因此很容易想象这个想法如何改变产品。
在每次重要构建之后（任何在主干中更新的内容，都需要通过单元测试），我们尝试至少让2个人测试该项目。主要是我们试图找到对计算机知识了解较少的人，因为我们发现设计复杂性而不是简单性太容易了。
我们使用DOxygen生成文档。目前我们没有将自动生成文档纳入构建流程，但我们正在努力实现这一点。
我们不进行代码审查。只要单元测试能正常工作，源码不会引发问题，那就可以了——但这是因为我们相信程序员的质量。在其他环境下可能行不通。
单元测试对我们的编程实践产生了巨大帮助。由于没有经过适当的单元测试，新代码不能被传输到主干，因此我们的主干有了相当好的覆盖率，并且分支上也有中等的覆盖率。然而，它并不能替代用户测试——只是达到那个阶段的辅助工具。
我们使用Bugzilla进行漏洞跟踪。我们不喜欢它，但现在它还能用。我们可能很快要么自己开发解决方案，要么迁移到FogBugz。我们的目标是在达到零已知漏洞状态之前不发布软件。正因为这种立场，我们对现有代码包的更新通常相当小。
因此，我们的流程通常如下：
我们的流程并不完美，但是完美流程意味着完美的人类和技术——这在短期内不可能实现。我们在规划过程中使用的纸张数量惊人——也许该与Dunder Mifflin签订合同了？
将特定项目的所有文件和电子邮件整理好，并通过一个中央位置使其对其他人可访问（我使用 MS OneNote 2007，喜欢它用于所有我的文档、进展、功能和缺陷跟踪等）。
所有会议（应尽量减少）都应该有行动项，每个行动项都分配给一个具体的人。任何口头协议都应写成书面文件。所有文档都添加到项目站点/仓库中（在我的情况下是 MS OneNote）。
在开始任何新的开发之前，要有一个关于系统将能够做什么（以及不能做什么）的书面文件。承诺它，但要灵活适应业务需求。这个文件应该有多详细？详细到每个人都能理解最终系统将能够做什么。
时间表很好，但要实事求是并对自己和业务用户诚实。我使用的基本准则是：发布质量和可用性较高的软件，而不是带有所有功能的错误软件。
在您的开发团队和开发人员与业务团队之间保持开放的沟通渠道，但在一天结束时，一个人（或几个关键人物）应该负责做出重要决策。
在适当的情况下进行单元测试。但不要过度沉迷于此。100%的代码覆盖率并不等于没有错误，并且软件按照规范正确运行。
确保有代码标准和代码审查。坚持标准，但如果对某些情况不起作用，则允许灵活性。
注释您的代码，特别是难以阅读/理解的部分，但不要把它变成小说。
如果您已经在处理那个类/方法，实施新功能、修复错误等，请回头清理您的代码。但不要仅仅为了重构而重构，除非您没有其他事情可做并且感到无聊。
最后也是最重要的一点：不要对任何特定的方法论或技术变得过于固执。从每个方面借鉴最好的方面，并找到适合您和您的团队的平衡点。
http://www.extremeprogramming.org/
因此，这包括故事卡、测试驱动开发、配对编程、自动化测试、持续集成、一键安装等内容。我们不太注重文档，但我们意识到需要制作足够的文档以创建可工作的软件。
简而言之：
