我正在寻找20个Scrum团队的解决方案，以解决如何在不同环境中推送代码的问题：
这里的难点是，许多团队将努力推动SIT，事情可能需要花费一些时间来部署，并且可能导致潜在的瓶颈。另外，我们需要确保我们的代码与真实的集成点（QA env）配合良好。 同样对于Scrum，我们什么时候应该将用户故事称为“完成”，何时进行SIT或质量检查？
我敢肯定，这已经被问过了，但是找不到确切的术语，请随时向我指出。
编辑：它是一种全新产品，外观整洁，目前尚无代码或管道。
答案 0 :(得分：1)
好的，您的确切问题是：您何时称呼用户故事完成？在Scrum中，它在可能可交付时已完成，因此在您的设置中：舞台。
现在，我希望这对您和您的团队来说都是不现实的。这是因为您在处理过程中遇到了许多障碍，您必须解决这些障碍才能真正完成CI / CD并在sprint中包含潜在的可释放代码：
连续集成。我并不是说您使用的服务器和平台/工具。我的意思是实际上在每个签到中集成每个人的代码。如果您有20个今天不这样做的团队，那么明天他们不会突然开始。一旦尝试，您将遇到各种实践，过程和体系结构挑战。您需要完成这些工作才能实现此目的。我最好的建议是，让公共领域的团队不断地相互融合，然后打破这些团队之间的障碍。即使这太多了，也可能只是每个团队每天要进行多次整合。坦白说，如果您还没有做到这一点，那么其余步骤就没有太大意义。
测试是在其他地方进行的。它发生在不同的阶段，不同的环境中，并且可能是在不同的团队中发生的。这是一个有两个原因的问题。如果在完成故事后进行测试，则可以加强这样的想法，即团队的工作是编写代码，而不是创建有效的可用功能。其次，这些错误报告将再次出现，然后必须对已完成和集成的工作进行重做，重做和集成。如果以前很难进行集成，则只需在其中添加一个乘数即可。
您是否有跨职能团队致力于增加价值？我在这里很难猜到，但是服务存根和困难的集成通常表明不同的团队正在使用不同的组件。这会为错位创造大量机会，从而加剧您的挑战。
好，最后一个。您需要整个团队维护环境。那是一个很大的危险信号。这意味着您的系统要么非常复杂，要么人们留下了很多松懈的结局，或者两者兼而有之。如果您要围绕同步其他团队来组建整个团队，则可能需要对您的问题进行创可贴。您的环境应可预测且稳定。这意味着与您的环境有关的大多数任务应该是自动化的，然后其他团队可以执行并非如此的奇怪任务。
这可能不是您想要的答案，但这可能是您要实现目标所要解决的挑战。