有时候，当我开始一个小项目（例如android应用）时，我不知道哪种方法最终会成功，而我只是尝试一种方法并尝试一下。但是，如果我以前从未使用过这种方法（对于我以前从未编程过的某种应用程序），那就像步入未知领域。我不知道要使用哪个库（也许我必须尝试几个库），而且有太多未知数（例如：如何在android中获取原始音频数据）
因此，我的开发过程如下：
如果我现在详细计划软件设计，那可能会浪费时间，就像计划没有地图的旅程一样。
这是敏捷开发的一部分吗？您如何处理软件开发中的未知领域？
Answers:
这与敏捷无关，但是人们会认为它确实与敏捷有关，因为这就是他们所认为的敏捷。嬉皮公社的无头鸡发育。
您正在做的是评估技术，因为您目前没有足够的经验来做出判断。这很好，而且永无止境，因为新的库，框架，语言和平台几乎每天都在出现。
实际上，如何处理未知数是一个非常好的问题，它取决于研究备选方案，评估备选方案，然后选择一种方案。
往往与敏捷相关联的技能在这里会有所帮助，其中涉及使代码易于重构和重构。TDD是一个很好的例子。它鼓励您考虑成果的发展。“此代码应产生此结果”，这可以使您集中精力并减少对实现目标没有帮助的代码量。
如果您遵循SOLID（首字母缩写词）原则编写代码，那么如果您选择错误，或者您的选择超出了预期，那么以后您将很可能替换库。
您问这样的问题很好。有太多的开发人员出于各种原因不会花时间选择正确的技术来冒“无知”的风险。在项目早期尽早犯错误。实验是关键，不是浪费，所以我认为您正在以正确的方式进行尝试。
根据项目的不同，如果您一个人在一个小项目上工作，那么在开发过程中进行技术研究和调查可能很有意义。尽管不是敏捷的一部分，但是当然可以使用敏捷方法来对此进行一些控制。但是，这使得该过程非常难以预测/或时间框。如果一个人从事一个完全属于您的小项目，可能会更好，甚至更快，让您的需求在学习的过程中得以展现。在此过程中使用良好的原则，并保持一致，您无需进行太多重构。
在工作中，我们使用看板，Scrum和更传统的瀑布方法。根据项目的不同，我发现具有明确定义的前期要求的复杂开发并非最适合敏捷，但很多人会不同意。
在我们甚至在一个敏捷项目（除了最简单的项目）上开始工作之前，我们都会创建一些文档。我们有一个模型（如果以ui为重点），一组需求和一个功能规范。
将要求开发人员从功能规范中创建技术规范，在此过程中，我们将指定技术并进行所需的任何前期研究。这个过程对我来说似乎非常重要，因为它使您有机会查看需求/功能规范中的差距-并向具有经验和系统知识的人员做出重大技术决策，以做出此类决策。
不过，重要的是，功能规范可能是项目符号列表，而技术规范通常是模型，其中包含一些项目符号和技术指导，在某些情况下可能只有3或4页。
即使在运行敏捷项目时，我们也会创建文档：
您会看到我们的敏捷过程中有一个小瀑布。
如果您是一个人工作，请创建一个前期模型（图表！）并进行试验并选择技术，然后在具有高层需求的概念时，继续前进并以敏捷的迭代方式进行开发，但要考虑好的原则和原则。保持一致，您将需要减少重构，而在重构时需要更多重构。
但是总的来说，如果涉及到实际成本（不是业余爱好），则在编写代码之前先知道自己在开发什么，但不要浪费太多时间来编写文档，因为随着您改变主意，文档将很快变得多余，并且应该当您变得更加了解情况时，请在开发过程中改变主意。您的项目可能会发生很大的变化，但是要从一个良好且定义明确的基础开始。