轻松访问最新文档是必须的。 对于敏捷/XP 环境，我个人的建议是建立一个项目 wiki 以用作中央文档中心。 当创建或修改特性/接口/功能时，开发过程的一部分应该是创建或更新该组件的文档。 一个开发人员花半个小时来充分记录一些东西可以节省其他六个开发人员每个人尝试自己解决问题的半个小时。 使用 wiki 来记录文档可以更轻松地进行快速编辑，允许多个编辑器编辑单个页面，并确保每个人都使用最新的文档（没有可能过时的“本地”文档副本）。
Interfaces should be clearly defined before the code is written. An interface definition can be altered later if necessary, but this should only be done with the collaboration of all teams that develop for and use that interface. Having a consistent, well-defined interface helps encapsulate parts of the system, and can make it much easier to re-use common components or libraries. Good encapsulation and modularization are a necessary prerequisite for effective code re-use between independent teams (I'm assuming some sort of version control system is used).
Easy access to up-to-date documentation is a must. For an agile/XP environment, my personal recommendation would be to set up a project wiki to be used for a central documentation hub. As a feature/interface/function is created or modified, part of the development process should be to create or update the documentation for that component. A developer taking half an hour to adequately document something can save a half dozen other developers half an hour each trying to figure it out on their own. Using a wiki for documentation can make it easier to make fast edits, allow multiple editors for a single page, and ensure that everyone is using the most up-to-date documentation (no potentially outdated 'local' copies of documents floating around).
We've grown very organically and as a result the user interface greatly reflects the organization of our company as opposed to the organization of content which our client would find intuitive.
That situation can occur when the interface is not treated as a separate, modular component. An interface should plug into the functionality beneath it but should not necessarily represent the structure of the underlying organization. I often see this sort of thing when an interface is built by 'hacking'; that is, a developer builds a new feature and modifies the UI just enough to support their feature, then the next developer does the same, etc etc until the entire UI has been cobbled together with no overarching design goals or principles. Do not underestimate the importance of the user interface or the difficulty of creating a high-quality, consistent interface. Dedicating an engineer (or small team in the case of a larger project) to design and maintain the user interface can greatly enhance the value of your product from the customer's point of view. Since the customer typically sees the user interface and none of the internal workings, the interface should be more than the product of 1% of the team's labor.
Implementing a "scrum of scrums" structure is fairly easy if you get all of the individual teams on the same track. Each day, each small group/team meets for a brief status report/scrum meeting, after which each small group's designated "leader" meets for another scrum on the next level "up the food chain". Since this can be repeated up numerous levels of hierarchy, it tends to work best when the small group scrums happen first thing in the morning, and each level of scrum has a hard and fast time limit (usually 15 minutes, or 2-3 minutes per person will suffice). The time limits are useful to prevent one team going overtime and delaying their leader from the next level of scrum meeting, etc.
最后，它需要管理层的支持来执行决策。 例如，如果除了一个团队之外的所有开发团队都达成了技术 X 的共识，并且一个团队坚持支持技术 Y，则可能是一个团队在另一家公司寻找新工作的时候了。
"Any alternative solutions to a scrum of scrums?"
Yes. An architect.
The job of an architect -- in this context -- is not to dictate the architecture.
The job of an architect is to coordinate among the teams. Meet with everyone on a regular basis. Participate in the scrums, help where help is needed.
Most importantly:
Act as governance over change requests.
Establish a shared vision among the various teams.
This requires the technical depth to understand everything that's going on, as well as the political skills to be sure everyone is being heard.
Finally, it requires management backing to enforce decisions. If, for example, the consensus among all development teams but one is technology X, and and one team is holding out for technology Y, it may be time for one team to find a new job in a different firm.
Having each developer assigned continually to the same piece of the system increases the differences across products. Reduce this by moving developers across these teams. It will also reduce information silos and increase their understanding of how the piece they are developing fits in the business. You shouldn't overdo this as well.
Regarding system's integration. These are different services with different needs, which all have their own context. It is ok for these applications to be focused on their own context, since that reduces plenty other problems.
What you want to do is make sure there are clearly defined points of integration between the services. It is about agreeing on how will the systems interact and the contracts of information involved. This should operate at the application level, as opposed to the database level. It is also about operations and information/intelligence on it, not about data. Here is a very nice article about enterprise architecture.
首先，您需要一个版本控制（我假设您已经在使用一个）。 确保为每个开发人员设置正确的权限，这样他们就不会“意外”破坏东西。 这应该使团队 A 的开发人员能够访问团队 B 的代码。
其次，为了确保团队 A 没有使用团队 A 中不可用/不完整的代码，团队 A 需要发布“可用/良好”的代码供其他团队使用。 这可以通过从特定的“可用/良好”修订版分支或仅发送“可用/良好”修订版号来完成。
最后，这一切都是为了在团队之间建立诚实和开放的沟通。 确保所有接口和角色都明确定义。
First, you need a version control (I assume you're already using one). Make sure to set the right privileges to each developer so they don't "accidentally" break things. This should give developers from Team A access to Team B's code.
Second, to make sure Team A is not using unusable/incomplete code from Team A, Team A needs to publish a "usable/good" code for other teams to use. This can be accomplished either by branching from that specific "usable/good" revision, or just sending out the "usable/good" revision number.
Lastly, it's all about establishing an honest and open communication between teams. Make sure all interfaces and roles are clearly defined.
I agree with S. Lott. You need an Information/UX Architect with power. That person should have the respect of developers by having worked on innovative projects before.
发布评论
评论（7）
我遇到过一些成功运行 Scrum of Scrums 的 CSM，但除非您已经具有 Scrum 经验，否则管理起来可能很困难。
I have met a few CSM's who are successfully running a Scrum of Scrums, but it can be difficult to manage unless you're already experienced with Scrum.
在编写代码之前应该明确定义接口。 如有必要，可以稍后更改接口定义，但这只能通过开发和使用该接口的所有团队的协作来完成。 拥有一致、定义良好的接口有助于封装系统的各个部分，并且可以更轻松地重用公共组件或库。 良好的封装和模块化是独立团队之间有效重用代码的必要先决条件（我假设使用某种版本控制系统）。
轻松访问最新文档是必须的。 对于敏捷/XP 环境，我个人的建议是建立一个项目 wiki 以用作中央文档中心。 当创建或修改特性/接口/功能时，开发过程的一部分应该是创建或更新该组件的文档。 一个开发人员花半个小时来充分记录一些东西可以节省其他六个开发人员每个人尝试自己解决问题的半个小时。 使用 wiki 来记录文档可以更轻松地进行快速编辑，允许多个编辑器编辑单个页面，并确保每个人都使用最新的文档（没有可能过时的“本地”文档副本）。
当界面没有被视为单独的模块化组件时，就会发生这种情况。 接口应该插入其下面的功能，但不一定代表底层组织的结构。 当通过“黑客”构建界面时，我经常看到这种情况； 也就是说，开发人员构建一个新功能并修改 UI 足以支持其功能，然后下一个开发人员执行相同的操作，依此类推，直到整个 UI 被拼凑在一起，没有总体设计目标或原则。 不要低估用户界面的重要性或创建高质量、一致的界面的难度。 从客户的角度来看，指定一名工程师（或大型项目中的小团队）来设计和维护用户界面可以极大地提高产品的价值。 由于客户通常会看到用户界面而看不到任何内部运作，因此界面应该超过团队 1% 的劳动成果。
如果您让所有单独的团队都处于同一轨道上，那么实现“scrum of scrums”结构相当容易。 每天，每个小组/团队都会举行简短的状态报告/scrum 会议，之后每个小组指定的“领导者”会在下一个级别“食物链上游”举行另一次 scrum 会议。 由于这可以在多个层次结构中重复进行，因此当小组 Scrum 在早上第一件事发生时效果最好，并且每个级别的 Scrum 都有一个硬性且快速的时间限制（通常为 15 分钟，或 2-3 分钟）每人就够了）。 时间限制有助于防止团队超时并延迟领导者参加下一级别的 Scrum 会议等。
Interfaces should be clearly defined before the code is written. An interface definition can be altered later if necessary, but this should only be done with the collaboration of all teams that develop for and use that interface. Having a consistent, well-defined interface helps encapsulate parts of the system, and can make it much easier to re-use common components or libraries. Good encapsulation and modularization are a necessary prerequisite for effective code re-use between independent teams (I'm assuming some sort of version control system is used).
Easy access to up-to-date documentation is a must. For an agile/XP environment, my personal recommendation would be to set up a project wiki to be used for a central documentation hub. As a feature/interface/function is created or modified, part of the development process should be to create or update the documentation for that component. A developer taking half an hour to adequately document something can save a half dozen other developers half an hour each trying to figure it out on their own. Using a wiki for documentation can make it easier to make fast edits, allow multiple editors for a single page, and ensure that everyone is using the most up-to-date documentation (no potentially outdated 'local' copies of documents floating around).
That situation can occur when the interface is not treated as a separate, modular component. An interface should plug into the functionality beneath it but should not necessarily represent the structure of the underlying organization. I often see this sort of thing when an interface is built by 'hacking'; that is, a developer builds a new feature and modifies the UI just enough to support their feature, then the next developer does the same, etc etc until the entire UI has been cobbled together with no overarching design goals or principles. Do not underestimate the importance of the user interface or the difficulty of creating a high-quality, consistent interface. Dedicating an engineer (or small team in the case of a larger project) to design and maintain the user interface can greatly enhance the value of your product from the customer's point of view. Since the customer typically sees the user interface and none of the internal workings, the interface should be more than the product of 1% of the team's labor.
Implementing a "scrum of scrums" structure is fairly easy if you get all of the individual teams on the same track. Each day, each small group/team meets for a brief status report/scrum meeting, after which each small group's designated "leader" meets for another scrum on the next level "up the food chain". Since this can be repeated up numerous levels of hierarchy, it tends to work best when the small group scrums happen first thing in the morning, and each level of scrum has a hard and fast time limit (usually 15 minutes, or 2-3 minutes per person will suffice). The time limits are useful to prevent one team going overtime and delaying their leader from the next level of scrum meeting, etc.
“对于 scrum of scrums 有什么替代解决方案吗？”
是的。 一位建筑师。
在这种情况下，架构师的工作不是决定架构。
架构师的工作是在团队之间进行协调。 定期与大家见面。 参与 scrums，在需要帮助的地方提供帮助。
最重要的是：
对变更请求进行治理。
在各个团队之间建立共同愿景。
这需要技术深度来了解正在发生的一切，也需要政治技巧来确保每个人的声音都能被听到。
最后，它需要管理层的支持来执行决策。 例如，如果除了一个团队之外的所有开发团队都达成了技术 X 的共识，并且一个团队坚持支持技术 Y，则可能是一个团队在另一家公司寻找新工作的时候了。
"Any alternative solutions to a scrum of scrums?"
Yes. An architect.
The job of an architect -- in this context -- is not to dictate the architecture.
The job of an architect is to coordinate among the teams. Meet with everyone on a regular basis. Participate in the scrums, help where help is needed.
Most importantly:
Act as governance over change requests.
Establish a shared vision among the various teams.
This requires the technical depth to understand everything that's going on, as well as the political skills to be sure everyone is being heard.
Finally, it requires management backing to enforce decisions. If, for example, the consensus among all development teams but one is technology X, and and one team is holding out for technology Y, it may be time for one team to find a new job in a different firm.
让每个开发人员不断地分配到系统的同一部分会增加产品之间的差异。 通过在这些团队之间调动开发人员来减少这种情况。 它还将减少信息孤岛，并增加他们对正在开发的产品如何适应业务的理解。 你也不应该做得太过分。
关于系统集成。 这些是具有不同需求的不同服务，它们都有自己的上下文。 这些应用程序可以专注于自己的上下文，因为这可以减少许多其他问题。
您想要做的是确保服务之间有明确定义的集成点。 它涉及就系统如何交互以及所涉及的信息合同达成一致。 这应该在应用程序级别操作，而不是在数据库级别操作。 它还涉及其上的操作和信息/情报，而不是数据。 这里是一篇关于企业架构的非常好的文章。
Having each developer assigned continually to the same piece of the system increases the differences across products. Reduce this by moving developers across these teams. It will also reduce information silos and increase their understanding of how the piece they are developing fits in the business. You shouldn't overdo this as well.
Regarding system's integration. These are different services with different needs, which all have their own context. It is ok for these applications to be focused on their own context, since that reduces plenty other problems.
What you want to do is make sure there are clearly defined points of integration between the services. It is about agreeing on how will the systems interact and the contracts of information involved. This should operate at the application level, as opposed to the database level. It is also about operations and information/intelligence on it, not about data. Here is a very nice article about enterprise architecture.
首先，您需要一个版本控制（我假设您已经在使用一个）。
确保为每个开发人员设置正确的权限，这样他们就不会“意外”破坏东西。
这应该使团队 A 的开发人员能够访问团队 B 的代码。
其次，为了确保团队 A 没有使用团队 A 中不可用/不完整的代码，团队 A 需要发布“可用/良好”的代码供其他团队使用。
这可以通过从特定的“可用/良好”修订版分支或仅发送“可用/良好”修订版号来完成。
最后，这一切都是为了在团队之间建立诚实和开放的沟通。 确保所有接口和角色都明确定义。
First, you need a version control (I assume you're already using one).
Make sure to set the right privileges to each developer so they don't "accidentally" break things.
This should give developers from Team A access to Team B's code.
Second, to make sure Team A is not using unusable/incomplete code from Team A, Team A needs to publish a "usable/good" code for other teams to use.
This can be accomplished either by branching from that specific "usable/good" revision, or just sending out the "usable/good" revision number.
Lastly, it's all about establishing an honest and open communication between teams. Make sure all interfaces and roles are clearly defined.
我同意S.洛特的观点。 您需要一位有能力的信息/用户体验架构师。 这个人应该因为之前从事过创新项目而受到开发人员的尊重。
I agree with S. Lott. You need an Information/UX Architect with power. That person should have the respect of developers by having worked on innovative projects before.