我记得不久前在Stack Overflow播客中，Jeff Atwood正在谈论赏金系统，他说他们在赏金奖励代码编写之前发布了赏金提供代码，因为几个代码不需要代码周。
这是否有标准术语？敏捷可以这种方式工作，但它没有必要。我正在考虑向客户提出建议，并希望使用正确的术语以及作为方法备份的任何信息。
本质上，该方法是发布一些功能不完整的代码，因为需要不完整功能的时间少于开发所需的时间。
答案 0 :(得分：5)
准时开发？类似于商业中just-in-time inventory的概念。
或者，不那么慈善，“翼翼”。
答案 1 :(得分：3)
这是恕我直言，你有时会得到机会，不是方法：例如，提供一个功能，允许在月初订阅月度通讯，发布一个月后发送简报的代码。这样做只是智能发布管理（即良好的工作优先级）。也许有人可以称之为机会发展（这是你在敏捷文献中可以找到的东西）。
答案 2 :(得分：1)
这个词是 Bounty Development 。
说真的，如果你在这个场景中查找你想要做的术语，恕我直言增量，不一定是不完整的。如果你有 bounty提供代码，你没有不完整的赏金代码，你有赏金提供代码。
这里没有什么是不完整的：它是一个可交付的（可交付的工作量）以一种检查和适应的方式提交到一个阶段（工作的常规节奏）。
经常提供工作软件， 从几个星期到几个星期 几个月，优先考虑 时间缩短。
Source: Principles of Agile Manifesto
我只想使用敏捷一词，只需要一个简单的解释（因为在地球上使用任何术语，你仍然需要解释它）：“在一个非常小的工件中创建软件，在更短的时间内每个部分的时间表都与持续的客户合作“。
答案 3 :(得分：0)
以下是一些可能有用的链接。我认为原型设计更接近你想要的，但我会留在其他链接中，以防万一你想添加一些在开发软件时可能有用的短语：
答案 4 :(得分：0)
打开Alpha或Beta（取决于完整性）
基本上，您知道代码库尚未针对所有功能进行固化，但无论如何您都将其发布给公众。
'alpha'区别可能适合处于初始开发阶段的项目。
'beta'区别通常适用于尚未成熟到第一个正式版本号（IE 1.0）的应用程序。
要小心，因为有risk inherent向公众发布不完整/未经测试的代码。
在Stack Overflow的情况下，发布不完整的代码/功能并不是什么大问题，因为该平台应该是under constant development/revision as per the user community。
答案 5 :(得分：0)
自杀？
我认为潜在的收益不会超过风险。