我的公司正处于从瀑布式开发到敏捷/ Scrum的过渡中。别的不说，我们被告知的期望是的，我们有新的工作，可测试（由QA）在每一天结束的功能。
我们的大多数开发人员每天损失约2个小时的会议时间和其他企业开销。这意味着在任何给定的6个小时（最好）的时间内，我们必须设计，编写，单元测试，构建和部署（带有发行说明）足够的代码，以产生可供QA使用的完整功能。我知道可以使用正确的CI设置来自动进行构建/部署/发布说明，但我们还没有。
我们还拥有一支庞大的海上队伍来编写我们的服务器端代码，而12小时的时差使这一点变得更加困难。
我们试图将故事分成狭窄的垂直部分，以尽可能快地完成端到端的功能，但是大多数日子过得很疯狂，我经常发现人们采取愚蠢而脆弱的捷径来确保QA的建立。在冲刺进行了几天之后，不可避免的缺陷开始出现并且必须适应相同的6小时窗口，此问题变得更加复杂。
对于敏捷团队来说，这是正常的步伐吗？即使我们设法实现CI设置，我也看不到我们如何能够保持这种步伐并仍然创建高质量的软件。
编辑： 这里有几个很好的答案。这让我意识到，我真正要问的是，敏捷团队是否应该每天提供新功能。我相应地更新了标题。
Answers:
这些天以敏捷的名义犯下的罪行使我感到难过。许多人都很难过渡。
敏捷宣言：“我们重视人员和互动，而不是流程和工具。” 当人们明显受到伤害时，这个过程是错误的。我不想告诉你如何做，但会分享我的做事方式。
在我的团队中，重要的部分是避免提交共享的回购代码，该代码可能会浪费团队的其余时间。仅从这种意义上讲，我致力于“每天交付可用的代码”。不要破坏质量检查。不要阻止其他开发人员。理想情况下，我从不检查任何错误。（哈哈）。
这并不意味着您不必每天都做一些事情。这意味着您应该只提交好东西，这样您每天都可以获取任何人提交的所有好东西。通过这种方式，车队不断向所有汽缸开火。
在我的团队中，质量检查始终如一。我生产商业产品，因此该项目永远不会结束，直到产品被淘汰为止。质量检查工程师测试可以测试的功能。质量检查工程师总是积压。没有足够的质量检查时间来测试或自动化我们理想中想要的一切。
如果开发人员需要几天的时间才能合并功能或修复程序的变更，那就很好了，如果可以帮助开发人员在冒着时间浪费时间之前正确地编写代码，则可以采用这种方法。开发人员可以将代码提交到其私有仓库或分支，而不会影响团队或质量保证。开发人员可以对从开发人员的存储库或私有分支构建的代码运行单元测试或回归自动化。在特别有风险的情况下，质量检查工程师会与开发人员合作在合并之前进行测试，以保护团队免受延迟。
从这个意义上讲，我会实践您的经理想要的。在过去的12年中，我的开发团队几乎每天都有可在共享存储库中工作的代码。我们几乎随时准备发货。有时我们无法实现这一目标，但我们对此不必太担心。有时是有意的，以适应主要工具的更改或困难的合并。
对我来说，敏捷宣言总结了1990年代出现的关于发展过程的新思想的精髓。我几乎是这些原则的真正信奉者，但是过程的细节可能会有所不同。如我所见，敏捷的重点是使您的流程适应产品和客户的需求，而不是成为流程的奴隶。
如果您昨天有工作软件，为什么今天不工作？如果您今天没有完成任何任务，那么今天的构建将与昨天相同。日常构建和发展速度是分开的。仅仅因为您拥有每日构建，并不意味着您在每个构建中都有新功能。
最终，某些功能完成并在主分支中签入后，您应该具有用于构建软件并运行测试的自动化过程。如果构建或运行测试存在问题，则会通知团队，他们会集中精力使它再次正常运行。这就是CI的工作方式，以及它如何帮助您始终发布有效的软件。
简短的回答：不。只是根本无法每天完成。
但是，敏捷团队应该在每个sprint中交付可用的软件或用户故事。通常，每天举行一次状态会议以查看进度和障碍。
关于质量软件，适当的持续集成（CI）流程将确保质量控制应用于少量工作（签入），并按配置的频率进行。它的目标quality of software是通过在完成所有开发工作后替代应用质量控制的传统做法，以改进并减少交付时间。
不，不应期望每天都提供新功能。并非所有功能都可以分解为如此小的尺寸，以使开发人员能够在约6个小时的开发时间内完成该功能。
如果您正在做Scrum，那么您应该至少进行2周的冲刺，其功能的大小大约需要0到8天才能完成。对产品负责人的承诺是交付新的，经过测试和验证的正确工作代码，这些代码可以在冲刺结束时投入生产。（注意：您不必实际将其投入生产，但目标是如果您愿意的话）
好的方法建议您设置一台CI（连续集成）服务器，在其中自动创建至少一个日常工作软件版本。想法是您在完成功能后立即签入代码，因此可以在下一个构建周期中进行，然后交由质量检查人员进行测试。
请记住，目标是在冲刺结束时完成并测试功能！您不需要等到冲刺的最后一天才进行质量检查，以进行构建，然后让他们测试所有功能。他们没有时间进行全部测试，您也没有时间修复任何错误...
如果您无法设置CI服务器，则应采取的做法是，每次开发人员签入完成的代码并声称他已完成某项功能并准备进行质量检查时，都需要为质量检查手动创建一个新版本。
有许多项目可以交付日常构建，这要归功于不断的集成，它们可以正常工作。至少在理论上。
这意味着它不一定包含新功能。也许只修复了一些小错误，或者一无所获。
从理论上讲，如果您无法每天为质量检查提供更多工作，则必须增加开发人员或减少测试人员。好主意！
告诉质量检查人员，测试完成后他们将得到一些测试。您需要向他们解释原因。
我认为您对“ CI”的概念感到困惑。您可能想访问Martin Fowler撰写的这篇出色的文章，介绍CI在实践中的工作原理。那应该可以正确回答您的问题。