谁在敏捷环境中修改受影响的组件？

在敏捷环境中，B类（与所有类一样）属于团队。我们称之为共享代码所有权。你应该检查工作代码;如果这意味着您需要调整B类以符合您对A类所做的更改 - 调整！更好的是，配对。     

“个人和过程与工具之间的互动。”事先与受影响的其他人沟通变更。除非代码是微不足道的，否则您可能无法理解更改的全部影响。即使你这样做，也要欠你的其他队友，让他们随时了解情况。 “不要破坏构建。”检查您知道的代码将破坏构建不是一个好主意。与受影响的其他人通信后，与他们合作以完成代码更改。尝试检查代码更改，因此至少每晚构建不会被破坏。 只是我的观点.... 短发     

  每当我想检查我的更改时谁会修改B级？我或班级'B老板？ 没有不尊重，我认为你的问题是如此基本，以至于它清楚地暗示你甚至没有对敏捷意味着什么的基本理解。好吧，也许这就是你问这个问题的原因。 以下是我的建议： 在这种情况下，你真的应该走向可能受到你的变化影响的另一个开发人员并快速面对面讨论这个，这个快速的对话可能会导致你们对编程进行配对以确保构建不会破坏，没有人受到影响。 请再次阅读所有敏捷原则，并写下您对每个原则的理解。在日常开发生活中实施这些原则。这是成为敏捷的唯一途径。没有任何证明或书籍可供参考，以使某人敏捷地成为敏捷。敏捷必须自我实现，因此每天都要练习它们，直到它们成为一种习惯。 因此，使用最有效的方法即f2f会话来传达“信息”。问题是在集体责任原则的基础上解决的，最理想的解决方法是结对编程。 参考： 敏捷原则 “最有效，最有效的方法 向开发中和开发内部传递信息 团队是面对面的谈话。“ 也是宣言中的一般敏捷指南： “响应遵循计划的变化”     

敏捷包括团队代码所有权和沟通 正如@Carl Manaster所说，代码属于团队。正如@rcravens所说，敏捷就是沟通。与B的作者快速会面并让他们知道您的建议已更改，以确保您了解您的影响。如果它很复杂，请与B的作者配对。更改完成后，如果您认为它可能会影响团队中的其他开发人员，请召开简短的团队会议并让他们知道更改。 顺便问一下，你的设计怎么样？ 您的问题也可能揭示出设计问题 - A和B可能过于紧密耦合。在测试工作并且您已实现更改后，我建议您检查代码并查看是否需要重构。 （请记住，TDD是Red / Green / Refactor）特别是，如果更改A类意味着您必须更改B类，那么您可能不会遵循SOLID实践的单一责任原则（SRP）部分。