由于我在写最后一个问题时做得不好，并且大多数答案都很好，但是根本不符合我打算提出该问题的方向，因此我删除了该问题并将其重现为该问题。

我是自己项目的开发人员，通常很小的事情，但是我有一些想法可能会变成FOSS项目。我相信文档(在不同程度上取决于特定项目和最终用户)，源代码控制和项目管理(包括错误跟踪，时间管理等)。但是，我不确定应该遵循多少正式程序。

在源代码管理下，仅保留一个README，关联的设计/需求文档以及代码内注释也许就足够了。也许有一个适合单个开发人员遵循的敏捷过程。或者，也许我应该为每个项目采用老式的瀑布模型。

如果我什至需要正式的流程，那么对于单独的开发人员来说存在或者可以采用哪些流程？

编辑：我意识到我正在做的任务，如文档和源代码管理。但是，我不确定问题的一部分。作为一个单独的开发人员，我应该采用更敏捷的方法(如果是，则采用Agile XP的"分支"吗？Scrum？RAD？)还是更常规的方法(瀑布或者螺旋式)？

解决方案

即使我们不需要过程来促进团队成员之间的良好沟通，过程也可以弥补以下事实：我们并不像18岁时那样自认为超人：)"文书工作"的类型和数量我们决定做什么取决于自己的优点和缺点。记性不好？每天写下设计和想法。好看的树木而不是森林？确保对要求和设计格外小心。好看的森林而不是树木？详细的任务清单，时间估算和经常交付的产品是朋友。

归结为：我们可能会搞砸什么，哪些流程有助于特定工作方式。

跟随你的心。

请记住，虽然我们现在可能是个单身，但那些项目可能会成功到足以让其他人加入行列。因此，尽管我们现在可能不需要所有多余的东西，但最终我们可能希望我们拥有一些设计文档和说明，以进行构建，管理源代码存储库等。

还请记住，当我们忘记了现在所知道的一切时，那些"其他人"可能就是我们。 (我们还很年轻-我们还不知道记忆消失的速度有多快。)因此，请想想为了自己的未来而想要记录的内容。

我们肯定需要一个过程，在管理和支持项目时会涉及很多非代码数据。没有流程，我们将很快遭受痛苦，重新散布设计思想，因为我们忘记了不做任何事情的所有充分理由，或者重新学习了如何分支svn b / c，而我们每个月只做一次。

有关设计，设计决策，操作等的文档对于任何重要项目都是至关重要的。

测试，源代码控制等都是良好的开发实践，无论项目大小如何，都应进行测试。

这是一个非常广泛的问题，但是也许我可以通过分享我的经验来提供帮助。我与我的几个朋友一起从事了一项业余游戏编码项目，将近5年的时间。我们是一群非常精打细算的开发人员，通常将我们的机器拖到一个公寓里待一个周末来开发项目。我的意思是，可以将它与单人工作进行比较，因为我们所有人都在决定重要的设计决策，等等。 '过程？'不，即使回想起来，我也找不到。

使源代码处于控制之中的一件事是遵循"敏捷开发"范式，我们决定从一开始就实施：无情地重构。我们做到了，天哪，它始终使整个游戏崩溃。但这确实使源保持了干净，当我们决定不时地寻求"稳定发行"时，一切似乎都变得很艰难。

提到我们链接到的页面，我说要按照流程进行。我是一个独立开发者，我遵循这些过程。在不了解要求和准备工作的情况下，我们无法编写软件。正如其他人所说，了解工作方式以及优点和缺点。此外，有时我们会陷入困境并需要一点外部帮助。谁都不知道。

整个过程需要时间(通常永远不会结束)，多年来，我已经杀死了太多的脑细胞，无法将所有细节存储在我的脑海中。思维导图，流程图和诸如OneNote之类的东西非常适合非编码的长期内存。尽量将大部分内容放在一个地方或者至少链接在一起，这样就不必记住要在哪里寻找它。