问题标签 [agile]

我们正在尝试遵循我工作的软件开发的敏捷方法。到目前为止它运行良好，但是，在迭代结束时，我们遇到了构建问题，并且花费了一天的时间来修复：应该专门用于测试的时间。

结果，我们的 QA 没有足够的时间在迭代结束之前完成测试。您如何处理这种情况——在迭代过程中不可预见的问题会影响任务？

在我公司的每个项目中，我们通常有 1-4 名开发人员/艺术总监/文案，您建议使用什么方法？敏捷？经验？Scrum？还有什么？（我知道它们都是本质上相同概念的变体，是的）

对于那些敏捷从业者...

在项目期间如何管理对数据库模式的更改？我的假设是，在敏捷项目中，所涉及的任何数据库的架构都会发生变化并被重构，就像代码库一样。

这个假设正确吗？如果是这样，您是否有任何特定的工具或流程可以用来帮助保持事情顺利进行？

多年来，我一直在听到和阅读有关敏捷的信息。我拥有一两本书，我喜欢这个主意。

我终于可以在我工作的地方推出这样的东西了，但我非常担心这是否适合我们：

• 这没有最小尺寸吗？对于三到四个星期的项目来说，前期的大型设计必须更有效率......对吗？
• 我们的客户通常要求固定价格。他们需要知道他们在处理什么，除非在特殊情况下，我们遇到了一个明显的黑洞，即使这样，人们也更愿意戴上帽子。那么，如果您要采用能够容忍持续需求变化的流程，您如何提供报价呢？
• 我知道敏捷可以在更复杂的项目中提供更好的成功几率，但它不会增加客户的成本吗？当然，还有不考虑的代价——也许我们又回到了最小尺寸问题。
• 您将如何向客户解释这种违反直觉的方法？非技术利益相关者可能没有经验来围绕瀑布之外的任何事情。
• 即使是内部项目，也有预算。我错过了什么？
• 最近似乎有人反对敏捷。其他东西会很快开始受到关注吗？

注意：我们是一个 5 开发商店，项目从一两天到几个月不等。我不相信有一种方法可以统治所有这些，但是找到足够灵活的方法来适应我们所有的项目会很棒。

非常感谢！

布赖恩·麦凯

敏捷开发方法的陷阱是什么？

我一直在努力寻找一个可以在敏捷开发/Scrum 的“午餐和学习”中展示的好视频。我们的组织主要是瀑布，大多数人甚至从未听说过敏捷开发，更不用说对该主题有任何具体的了解了。那里有很多很棒的资源谈论敏捷，但它们似乎都假设了敏捷的基本工作知识。对于那些一无所知的人，我找不到一个很好的、脚踏实地的、关于敏捷开发的介绍。

谁能提供这样的链接？

提前致谢。

我正在从事的项目正在尝试提出一种解决方案，使数据库和代码变得敏捷，并且能够一起构建和部署。

由于应用程序是代码加上数据库模式和数据库代码表的组合，因此除非您拥有与代码一起进行版本控制的数据库，否则您无法真正拥有应用程序的完整构建。

我们还没有想出一个好的敏捷方法来进行数据库开发以及敏捷/scrum 环境中的代码。

以下是我的一些要求：

1. 我希望能够拥有一个与系统的完整构建相对应的 svn 版本号。
2. 我不想将二进制文件签入数据库的源代码控制。
3. 开发人员需要能够将代码提交到持续集成服务器并一起构建整个系统和数据库。
4. 必须能够自动部署到不同的环境，而无需在构建服务器上进行原始构建以外的重建。

（更新）我将在此处添加更多信息以进一步解释。

没有 OR/M 工具，因为它是一个包含大量代码的遗留项目。我已经阅读了敏捷数据库设计信息，并且孤立的这个过程似乎有效，但我正在谈论将它与主动代码开发相结合。

这里有两个场景

1. 开发人员签入需要更改数据库的代码更改。开发人员应该能够同时签入数据库更改，以便自动构建不会失败。

2. 开发人员检查数据库更改，这应该会破坏代码。自动化构建需要运行和失败。

最大的问题是，这些东西如何同步起来。没有“签入数据库更改”之类的东西。现在，数据库更改的应用程序是一个人必须做的手动过程，而代码更改是不断进行的。它们需要一起制作并一起检查，构建系统需要能够构建整个系统。

（更新 2）这里再添加一个：

你不能降低生产，你必须修补它。重建整个生产数据库是不可接受的。

我有一个开发人员团队，分布在全球不同时区。

在这样的团队中实现最大生产力的最佳工具是什么？

我在寻找：

• 源代码控制
• 错误跟踪
• 构建管理
• 任何其他可能有帮助的事情

谢谢

由于预算限制，在一个采用敏捷开发实践的项目中间，我们不得不解雇 3 个软件测试承包商。管理态度是投入同等数量的全职机构来弥补这一点。敏捷开发是否允许这种中断？我想知道有没有人遇到过类似的情况，是怎么处理的？

随着我越来越多地将敏捷思维吸收到我的工作方式中，yagni（“你不会需要它”）似乎变得越来越重要。在我看来，这似乎是过滤掉被误导的优先事项并决定下一步不做什么的最有效规则之一。

然而，yagni 似乎是一个在 SO 中几乎没有被提及的概念。我进行了强制性搜索，它只出现在一个问题标题中——然后是次要角色。

为什么是这样？我是否高估了它的重要性？

免责声明。为了抢占响应，我相信我会反对，让我强调一下 yagni 是quick-and-dirty 的对立面。它鼓励您将宝贵的时间和精力集中在获得您确实需要的零件上。

以下是人们可能会提出的一些热门问题。

我的单元测试是根据用户要求还是框架结构选择的？

我是否安装（并测试和维护）单元测试，因为它们脱离了框架？

有多少由我的框架生成的代码我从未看过（但总有一天可能会咬我，即使是 yagni）？

我花了多少时间在我的工具上而不是用户的问题上？

结对编程时，观察者的角色价值往往在于“yagni”。

你使用 CRUD 工具吗？它是否允许（不，鼓励）您将其用作 _RU_ 工具或 C__D 工具，或者当您只需要一两个代码时，您是否正在创建四段代码（加上四个单元测试）？